<div dir="ltr">On Fri, Jan 10, 2014 at 10:47 PM, Code Raguet <span dir="ltr"><<a href="mailto:iraguet@activitycentral.com" target="_blank">iraguet@activitycentral.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hi, Emil. Awesome work!<div><br></div><div>I'd like to collaborate with the collaboration.js API design and implementation.</div><div>I'll ping at IRC</div></div>
</blockquote>Thank you. I'm looking forward to working with you.<br>My activity on this will probably drop after this week ends.<br><div><div><br>On Sat, Jan 11, 2014 at 2:34 AM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>first
 of all, I think having collaboration in sugar-web would be more than 
awesome, and I like the idea of using TogetherJS. The main question to 
me seems that of the interaction with the existing telepathy stuff.<br></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div><div><div><div> 
<br></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>I
 must say I'm not very familiar with it, but it's known to not be 
reliable. And putting another out-of-process communication layer on top 
of dbus feels bad. <br></div></div></div></div></blockquote><div>I 
thought that I was the only one not being able to get telepathy to work 
for collaboration. To be honest, I was never able to get a single sugar 
activity in collaboration. GTD activity with TogetherJS was the first one.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div><div>So
 I'm wondering if it would be better to develop this as a separate 
collaboration framework, initially targeted at web activities only. I 
don't know the mesh view code very well but it seems like that would be 
the only place where the two systems would need to interact and merging 
the two data sources is, although annoying, probably not rocket science.
 That would also allow us to reuse the TogetherJS server.<br>
<br></div>The only real downside I see is that it doesn't cover the 
off-the-school-server case. Though does the current protocol really 
cover it, given how unstable it is? I wonder if a low-tech solution 
would cover the case more reliably even if not as transparently. Say, 
the teacher or one of the students runs the server and the rest connects
 to it.<br></div></div></blockquote><div>While I was working offline, I 
ran a local server on my machine. I had no problems with it. I'd say it 
worked better than Mozilla's one.<br></div>Yet still, everything 
would rely on this one server and if it stops working for some reason, 
the collaboration network will be lost.<br><br>On Sat, Jan 11, 2014 at 2:53 AM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div>Thinking aloud here really.<br><br></div>If
 the approach you took is less work then making a separate framework, 
doing presence only with telepathy might be a good first step. But I'd 
rather go in the direction of both python and js activities doing 
collaboration through a WebSocket server then trying to use telepathy to
 bridge between websocket servers. If nothing else because of the mess 
of protocols, (with associated complexity) that the second approach 
would make (jabber | avahi + dbus + websockets).<br></div></blockquote><div> I decided to go with telepathy, only because normal sugar activities use it. I thought it would be best this way.<br></div><div>But as you mentioned, telepathy seems to be unreliable...<br>
</div>Can a similar web server be set up like <a href="http://jabber.sugarlabs.org">jabber.sugarlabs.org</a> is?<br><br><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Jan 11, 2014 at 1:19 PM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote><div>As mentioned above, I
 decided to go with the same protocols, so that sugar's core can remain 
untouched. As you mentioned below, all the collaboration stuff have to 
be reworked (invites, network view, etc.).<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>3)
 In my opinion, Web Collaboration without a server (XS Server or an 
Internet Server) has no sense. So I don't think we have to handle the 
complexity for a stand alone collaboration into web activities.</div></div></blockquote><div>Most of (if not all) of my work on the TogetherJS integration was done offline.<br></div><div>The activities don't really need an Internet connection and I think that supporting web collaboration locally is needed.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div>4) TogetherJS is nice but I think that its GUI is too intrusive and
 force us to respect some GUI stuff that are not really compliant with 
Sugar UI. So, I'm feeling more comfortable with a more low level API. 
Suraj is currently experimenting low level presence API using directly 
Web Socket API. I wonder if we need a high level API.</div></div></blockquote><div>At
 first when I decided to work on collaboration for web activities, I 
wanted to make it low level, with basic syncing capabilities. But I was given the opportunity to test out TogetherJS and I liked it for the extra featues it offers.<br></div><div>TogetherJS
 provides collaboration between pages (and possibly between activities).
 It has a chat integrated with it. It can work without flaws when 
syncing between 2 users with different page layouts (responsive design). Children can see each other's pointers, and follow their buddies to other pages.<br></div><div>Most importantly the library lets activity authors worry about their own web activity collaboration, while still providing some extra featues.<br>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div>5) I'm thinking to integrate collaboration in my Sugarizer 
prototype [1]. If we could reproduce all presence features in our Sugar 
web collaboration API, I could fully reproduce network view, 
invitation/join in Sugarizer. So, when Sugar Web Activities will work in
 Sugarizer, users will have a full featured Sugar collaboration 
experience. It's why I think we should have a full control of 
collaboration implementation instead of depending of a tier API.</div></div></blockquote><div>Writing a low level API would not be hard. It's the high level stuff from TogetherJS that will be lost.<br></div><div>Don't get this wrong, I'm not all for TogetherJS. It's just one of the many possibilities.
 I was given this library to work with and I liked for the things it 
gives. I took the simpler approach of using it, instead of rewriting it.<br></div><div>I, too, don't like many of it's GUI stuff. But I think that they can be reworked.<br><br></div><div>Regards,<br>Emil Dudev<br>
</div></div></div></div></div></div>