[Sugar-devel] Collaboration support for sugar web activities

[Daniel Narvaez]

Very interesting! Couple of initial questions, trying to understand better:

* Why did you go with a separate web activity instead on integrating
directly in the shell?
* Would it be possible to implement this without adding to apisocket and
thus making it sugar specific?


On 20 January 2014 00:09, Emil Dudev <emildudev at gmail.com> wrote:

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


-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140120/498b0a7c/attachment-0001.html>