<div dir="ltr">It might not come that easily but I think we need to support non-degraded collaboration between web activities inside Sugar. We don't need to interact with telepathy to do that, just with the UI layer. Telepathy and a new API can co-exist pretty easily.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 12 January 2014 11:20, Lionel Laské <span dir="ltr"><<a href="mailto:lionel@olpc-france.org" target="_blank">lionel@olpc-france.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">Collaboration means exchanging data between activities. It's the easy part because we could found lot of technologies that could do that: webRTC, web sockets or any higher layer API on top of it (like the nice TogetherJS API).</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">BTW today collaboration in Sugar means also:</div><div class="gmail_extra">- include a button "share" in the toolbar of the activity,</div><div class="gmail_extra">

- see shared activities in the network view near the buddy icons,</div><div class="gmail_extra">- join a shared activities in the network view so Sugar could launch it in the shared context,</div><div class="gmail_extra">

- send invitation that Sugar will put in the border of the invited users.</div><div class="gmail_extra"><br></div><div class="gmail_extra">None of this features will come easily if we don't reuse Telepathy in Sugar web collaboration because all of these features are handled by Sugar core.</div>

<div class="gmail_extra">It's what I called "degraded collaboration experience": Sugar web activities will have to implement invitation outside Sugar core.</div><div class="gmail_extra"><br></div><div class="gmail_extra">

Because, by definition, Sugarizer can't use Telepathy, it's a place where I hope to reproduce the full experience on top of the collaboration API we'll decide to choose.</div><div class="gmail_extra"><br></div>

<div class="gmail_extra">            Lionel.</div><div class="gmail_extra"><br><div class="gmail_quote">2014/1/11 Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im"><div>On 11 January 2014 12:19, Lionel Laské <span dir="ltr"><<a href="mailto:lionel@olpc-france.org" target="_blank">lionel@olpc-france.org</a>></span> wrote:</div>

</div><div class="im"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div>1) Sugar Web collaboration should be different than Sugar Collaboration. I think that trying to join both will expand complexity. Plus I don't see any use case where a Sugar Web Activity need to communicate with a Sugar Python Activity.</div>



<div><br></div><div>2) Of course if Sugar Web collaboration is different from Sugar Python Collaboration, it ask the question how to handle network view, activity invitation, join an activity, ... So invitation has probably to be handle into each web activity and we'll have a degraded collaboration experience - except in Sugarizer (see below).</div>



</div></blockquote><div><br></div></div><div>Not quite understanding this. Are you saying that when running inside Sugar web activities will provide a degraded collaboration experience? Why?<br></div></div></div></div></div>

</blockquote></div><br></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Daniel Narvaez<br>
</div>