[Sugar-devel] Collaboration support for sugar web activities

[Emil Dudev]

Please don't look at the poor javascript code :(

I created a web activity that can act as sugar's mesh for web activities
(with a few lines of code it should work for normal activities, too).

This time I went the other way around. Instead of sending invites, when an
activity is shared, everyone on the mesh can join it (it was easier to
implement). Normal invites could also be implemented, I just have to work
on integrating it with sugar's frame (for the invite notification).

Since this 'new mesh' is a web activity, it can be opened with a normal
desktop browser. Yet it will have little to no functionality. The simplest
explanation: the mesh can not know the path of an activity to open. With a
little work, this problem can be solved.

For the past 2 days I went deep into TogetherJS and I no longer believe
that it will suit sugar's needs.
The first reason is a WebKit bug. I noticed that when a CSS transform
property is used, the screen will go blank (gray). I manually edited
TogetherJS' jQuery modifications to not include CSS transforms, yet this
bug still happens. I have not yet found the problem. Although this is a
WebKit bug (it does not happen outside of sugar), it is one of the reasons
to drop TogetherJS.
The second one is the communication protocol. Although it is quite easy
(the server just replies the messages to all clients and lets them handle
everything), the protocol isn't much secure and may cause more traffic than
needed. I don't expect a kid to look at the code and 'hack' the protocol,
yet I still don't like the idea of leaving everything to the clients.
An other reason, although not much of a problem and more a feature, is the
fact that TogetherJS syncs every single mouse move, mouse click, form
change, input field update... These are lots of unneeded stuff.

As it was discussed earlier, a low-level API can work fine for sugar and it
won't be hard to create such an API. The thing that will be lost (and hard
to implement) are the many neat high-level features of TogetherJS.

About what I made and how to test it:
The sugar-net web activity is the 'mesh'. And a nice activity to test with
is the modified gtd-activity.
Once the sugar-net activity is started, it will communicate with a WebMesh
class in apisocket.py.
When a web activity (like gtd-activity) is shared, it will appear as a
shared activity when you hover the mouse over the XO icon in the sugar-net
activity.
When you click on it from an other mesh activity (an other instance of
sugar), it will automatically start the web activity (gtd-activity) and the
shared session will begin between the two.

Both sugar-net and gtd-activity still use Mozilla's hub server for the
communication.

sugar-toolkit-gtk3:
https://github.com/edudev/sugar-toolkit-gtk3/tree/webcollaboration
sugar: https://github.com/edudev/sugar/tree/webcollaboration
gtd-activity: https://github.com/edudev/gtd-activity/tree/collaboration
sugar-net: https://github.com/edudev/sugar-net

Emil Dudev



On Sat, Jan 18, 2014 at 4:20 PM, Emil Dudev <emildudev at gmail.com> wrote:

> I'm not quite sure.
>
> One way to do it is to use 1 class as the client and integrate the class
> into the current mesh box (neighbourhood.py). This would probably mean that
> normal sugar activities could use this 'new protocol'.
> An other way would be to use a web activity as the client. I'm not sure
> how exactly will I have to handle the activity -> sugar communication and
> pass the invites.
>
> If going with the second approach I'd have to rewrite the whole
> neighbourhood view in HTML/javascript. And with this an other question
> arises: How much of sugar's core can be rewritten in HTML/javascript.
> One of TogetherJS's features is to follow your friends around pages. I
> think it's limited to a single domain, but I believe I can use it.
>
> I believe that the first approach would be easier, but with all this talk
> about new frameworks for web activities and going multi platform, I'll
> choose the second approach.
>
> Emil Dudev
>
>
>
> On Sat, Jan 18, 2014 at 1:19 PM, Daniel Narvaez <dwnarvaez at gmail.com>wrote:
>
>> Interesting! Are you planning to use a js actitvity or a python one as
>> client?
>>
>>
>> On 18 January 2014 01:21, Emil Dudev <emildudev at gmail.com> wrote:
>>
>>> Busy month...
>>>
>>> Anyway, I checked out telepathy and tried to fix the many protocol
>>> problems. Sadly, I gave up pretty easily. I suppose it would be easier to
>>> rewrite the whole process from scratch.
>>>
>>> Today I was able to recreate the basic functionality of TogetherJS'
>>> server. From a nodejs server, I rewrote it in python (using gwebsockets).
>>> This will give me the ability to customize it freely.
>>>
>>> Tomorrow I plan on building the basic invitation process using web
>>> sockets. I suppose it will be more reliable than telepathy. And it would
>>> possibly be better for an Android app or other systems with limited
>>> functionality.
>>>
>>> About WebRTC: I really think that peer-to-peer connections are needed.
>>> But at this point, I'll go with client-server connections.
>>>
>>> gwebsockets: https://github.com/edudev/gwebsockets/tree/master
>>> websocket-server: https://github.com/edudev/web-reply
>>>
>>> Emil Dudev
>>>
>>> On Sun, Jan 12, 2014 at 8:51 PM, Daniel Narvaez <dwnarvaez at gmail.com>wrote:
>>>
>>>> On 12 January 2014 19:01, Emil Dudev <emildudev at gmail.com> wrote:
>>>>
>>>>> About the telepathy part to send only the invites and establish the
>>>>> connection:
>>>>> I can't seem to be able to complete the invitation accepted process.
>>>>> Sometimes it works, sometimes not (mostly not). For normal sugar activities
>>>>> it's the same (with the exception that with them it mostly works, at least
>>>>> I think it works).
>>>>> Exchanging the TogetherJS ID is not a problem. The invited user can't
>>>>> seem to connect to the telepathy channel properly.
>>>>> As you noted above, it's a protocol mess.
>>>>> If telepathy is completely dropped for web activities, then a question
>>>>> arises: how to send the invite with the unique ID?
>>>>>
>>>>
>>>> I don't know the details of the current invitation protocol. I suppose
>>>> you could register a "private" activity with the server and then send a
>>>> token to the invitee. Making this up as an example, not really well thought
>>>> :)
>>>>
>>>>
>>>>> Also, I still don't like using 1 server and having everything else
>>>>> depend on that 1 server. The server would most likely have to process a lot
>>>>> of traffic.
>>>>> Would it be possible to use a peer to peer connection with web
>>>>> sockets? Browsers don't support this, with reason. But if sugar's core is
>>>>> used, it should be possible.
>>>>>
>>>>
>>>> Did you investigate WebRTC? If nothing else I suspect it would allow to
>>>> exchange data between peers. I'm not sure if it provides any facility that
>>>> we could use to share presence information, i.e. a shared
>>>> buddies+activiities list. That's the really hard problem to solve if you
>>>> want fully p2p communication.
>>>>
>>>
>>>
>>
>>
>> --
>> Daniel Narvaez
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140120/51187736/attachment.html>