[Sugar-devel] Collaboration support for sugar web activities

[Emil Dudev]

On Mon, Feb 17, 2014 at 9:43 PM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

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

The thing I'm facing is that there is telepathy 'magic' code both in
sugar's core and sugar's toolkit (per activity/process). I writing 'magic',
because I don't understand it, and I have tried.
If sugar's core is responsible entirely for the meshbox, it should know
which of the user's currently running activities are shared, so it can
announce it.
If I make the activity responsible for itself with the server (regarding
the meshbox), it would mean that each activity will open an extra
connection to the server. Which is something I want to avoid. Instead, my
plans were to have 1 connection to the server - a class in sugar's core,
with the needed interface.
>From my understanding of telepathy, even though each activity has it's own
client, there is one connection (I might be wrong here).
An activity would either way have 1 connection to the server (which will be
for activity related stuff). If an activity opens an extra connection to
the server (the one for the mesh box), the problem will be that it would
need info from sugar's shell.

One thing that might be a good idea, is to change the server. As mentioned
several times, the server currently just replies messages between clients.
This leaves the clients to handle the protocol, but it mostly causes extra
bandwidth - a client will definitely receive a message multiple times, just
because an other client has asked for it. By making the protocol a bit more
complex to the server side, I should be able to find an optimal solution.

Using dbus to share information is a good idea, but it's something I try to
avoid.
What if a web activity is shared. Web activities don't have a dbus service,
but a simple one can be added. Still... all the code is in javascript. That
javascript has to notify apisocket, and it should notify the service, which
should notify the shell, which will notify the client. That's chain is a
bit long. Not that I haven't already implemented more than half it in my
early attempts, and of course deleted the code and thought of something
better (at least I'm hoping it's better).

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

Yes, that is the buddy's contact_id. Solving duplicates in an other step
will save me a lot of time (at least now).
I'm either thinking for zero backward compatibility or I'm thinking too
much for the future.

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

Sadly, no. Different telepathy handles are passed around neighborhood.py,
buddy*.py, invite*.py (and I'm not sure where else). In my opinion, classes
which should not know anything about telepathy, have such things are member
variables. Yet, I can't say that I have much experience, so I'm probably
wrong.


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

I'm not exactly sure about the number of such changes, that have to be
done. But it should be possible.
My concern is that the number of classes to change will be... not little
(although the changes should be small and easy, with most classes).

Emil Dudev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140219/14a0449a/attachment-0001.html>