[Sugar-devel] Collaboration support for sugar web activities

[Daniel Narvaez]

On 16 February 2014 20:43, Emil Dudev <emildudev at gmail.com> wrote:

> Hello,
>
> It's been a long time...
>

Hi Emil!


> To be honest, I haven't worked much on this.
> I've been following the Sugarizer project and I'm not exactly sure how
> sugar web collaboration will continue.
>

As you might have seen in another thread, we are trying to get the
sugar-web bits of Sugarizer merged back into upstream sugar-web. I don't
know the status of Lionel effort on collaboration, but I think he is not
looking into integration with the current framework. The stuff you are
pointing out below is exactly what we need to figure out for that
integration to happen!


> Anyway, when I last tested some things 2 weeks ago regarding telepathy and
> tried to setup a parallel websocket protocol for collaboration, I stumbled
> upon some difficulties. Today I managed to fix some things in my code and
> I'm hoping to get a second opinion.
>
> As mentioned above, I've tried to set up a websocket protocol for activity
> collaboration (including non-web activities and the mesh box/neighborhood
> view). Sadly, I'm having difficulties with sugar's code, as there isn't a
> good abstraction layer and telepathy is somewhat everywhere.in the code.
> What I've currently managed is to just display the users in the
> neighborhood view. I have yet to add support for invites in this new
> protocol.
> The problems I have are:
> 1. from sugar's core I can only know which activities are currently
> running, while I need a list of only the shared activities (and their share
> scope). Telepathy does this by having it's code both in sugar's core and in
> sugar's toolkit.
>

Can you explain why the shell needs to know about shared activities? I'm
thinking the activity could register those activities with the server and
the shell get them from the server together with activities shared by other
users.

If we really need the shell to know I think we should add a property to the
existing activity dbus service.

2. In order for the two protocols to run parallel and to not have
> duplicates on the meshbox, I'd need some sort of telepathy contact ID and a
> buddy key (I have no idea where to get these from).
>

Is that BuddyModel contact_id maybe? I would suggest to handle the
deduplication in a second step by the way, not really important for a first
prototype.


> Also, telepathy room handles and buddy handles seem to be passed around
> between instances of different types (this is what I meant by 'telepathy is
> everywhere in the code').
>
>
Is this all inside neighborhood.py?

>From a quick look to it, what I'd suggest is to rename Neighborhood ->
TelepathyNeighborhood, ActivityModel -> TelepathyActivityModel, BuddyModel
-> TelepathyBuddyModel. Then write WebsocketNeighborhood,
WebsocketBuddyModel, WebsocketActivityModel with exactly the same public
interface. Finally write a new ActivityModel which just merges
WebsocketNeighborhood and TelepathyNeighborhood (it should not be hard, it
looks like a list of activities/buddies with signals for changes).

Are there abstraction leaks that makes that impossible or problematic?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140217/e1ac6449/attachment-0001.html>