[Sugar-devel] Collaboration support for sugar web activities

[Emil Dudev]

On Wed, Feb 19, 2014 at 1:17 PM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> With making the protocol more complex do you mean that the activity would
> send both presence information (the registration stuff you mention) and
> messages for other clients on the same channel? Or would registration still
> go through the shell?

Mostly yes.
An activity knows it's color, it's bundle, it's name. I'm not sure if it
knows it's activity_id, but it wouldn't be hard to get it.
I'm trying not to think of it as 'buddy creates such activity', but
'activity is created/shared' and 'buddy joins activity'.
I think this would be a good way to implement it.

Emil Dudev

On Wednesday, 19 February 2014, Emil Dudev <emildudev at gmail.com> wrote:

> On Wed, Feb 19, 2014 at 2:36 AM, James Cameron <quozl at laptop.org> wrote:
>
>> On Wed, Feb 19, 2014 at 02:00:07AM +0200, Emil Dudev wrote:
>> > 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.
>>
>> Why do you want to avoid an extra connection?
>>
>> I speculate:
>>
>> Are you that short of resources on your target platform that an
>> additional TCP/IP connection is a concern?  Is it the latency of
>> starting an additional connection that makes this unwieldy?  Is your
>> server limited to a specific number of simultaneous connections?
>>
>> Since the decisions were made for the Sugar core in 2006, much has
>> changed, and server and network resources are no longer as
>> constrained.  You should feel less constrained, and if there is doubt
>> you should test.
>>
> Resources are not a problem (yet).
> I want to avoid the extra connection (per activity), mostly because there
> is no reason for it. The only thing that connection is for, is to
> 'register' a shared activity, by sending 4-5 of it's properties (activity
> id, bundle, color, name). I find that this is a waste of resources.
>
> For now, I think it would be best to make the protocol more complex on the
> server side. This should eliminate the need for the extra connection. And
> (thinking again for the future) it should work well with activities ran
> from a normal browser (not inside sugar).
>
> Emil Dudev
>


-- 
> Daniel Narvaez
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140220/803a5cfc/attachment.html>