[Sugar-devel] Collaboration support for sugar web activities

[Emil Dudev]

On Fri, Jan 10, 2014 at 10:47 PM, Code Raguet
<iraguet at activitycentral.com>wrote:

> Hi, Emil. Awesome work!
>
> I'd like to collaborate with the collaboration.js API design and
> implementation.
> I'll ping at IRC
>
Thank you. I'm looking forward to working with you.
My activity on this will probably drop after this week ends.

On Sat, Jan 11, 2014 at 2:34 AM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> 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.
>

>
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.
>
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.


> 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.
>
> 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.
>
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.
Yet still, everything would rely on this one server and if it stops working
for some reason, the collaboration network will be lost.

On Sat, Jan 11, 2014 at 2:53 AM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> Thinking aloud here really.
>
> 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).
>
 I decided to go with telepathy, only because normal sugar activities use
it. I thought it would be best this way.
But as you mentioned, telepathy seems to be unreliable...
Can a similar web server be set up like jabber.sugarlabs.org is?


On Sat, Jan 11, 2014 at 1:19 PM, Lionel Laské <lionel at olpc-france.org>wrote:

> 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.
>
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.).

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.
>
Most of (if not all) of my work on the TogetherJS integration was done
offline.
The activities don't really need an Internet connection and I think that
supporting web collaboration locally is needed.


> 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.
>
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.
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.
Most importantly the library lets activity authors worry about their own
web activity collaboration, while still providing some extra featues.


> 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.
>
Writing a low level API would not be hard. It's the high level stuff from
TogetherJS that will be lost.
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.
I, too, don't like many of it's GUI stuff. But I think that they can be
reworked.

Regards,
Emil Dudev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140111/9f30f598/attachment.html>