[Sugar-devel] On Sugar 0.84 - status of the "Chat/collab leader" issue...

Tomeu Vizoso tomeu at sugarlabs.org
Sun Nov 8 06:36:24 EST 2009


On Sat, Nov 7, 2009 at 17:40, David Van Assche <dvanassche at gmail.com> wrote:
> Hi,
>    So I was looking over the code with some of the #telepathy guys who are
> also under the impression that sugar.presence code could be causing many of
> the collab problems. Main issue is redundancy of code... a lot of what is
> happening in sugar.presence already happens in telepathy (actually there are
> even comments in sugar.presence code stating this) but until we know to what
> level activities are using sugar.presence, we can't really do anything...
> since activities would break, I guess we'd need to know what in the
> sugar.presence modules is being really actively used to migrate to MC 5...
> and give a warning or something, or keep some kind of sym links to the old
> functions... I dunno, kinda above my level of expertise...

Yes, info about presence is duplicated in several places. Any bugs at
each layer can cause the unreliability we see.

Regards,

Tomeu

> regards,
> David van Assche
>
> On Fri, Nov 6, 2009 at 2:02 PM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
>>
>> On Wed, Nov 4, 2009 at 13:16, Benjamin M. Schwartz
>> <bmschwar at fas.harvard.edu> wrote:
>> > Martin Langhoff wrote:
>> >> On Tue, Nov 3, 2009 at 9:54 PM, David Van Assche <dvanassche at gmail.com>
>> >> wrote:
>> >>> moving to mission control 5 and letting go of the admittedly
>> >>> antiquated sugar presence now
>> > ...
>> >> If you play with a major component replacement
>> >>
>> >>  - test it for scalability & stability over wifi before doing a lot of
>> >> integration work
>> >
>> > It's worth noting that moving from the Sugar Presence Service to Mission
>> > Control 5 would not alter our network protocols.  This is purely a
>> > change
>> > in how the client software is organized.  Neither regression nor
>> > improvement in wireless network performance should occur.
>>
>> Was about to say this, the work means making sugar activities' code
>> more similar to GNOME apps, while also removing a daemon. This could
>> have some effect on how the network is used, but chances are it won't.
>>
>> As a first step in removing the PS, I think we should try to implement
>> the python presence API with MC5 instead of PS. Then we can either
>> drop the PS or make it a compatibility shim with MC5 while activities
>> such as eToys make the move.
>>
>> We can also take the chance to develop a better API if there's need for
>> it.
>>
>> But in any case, we need to do some exploration now before we can
>> discuss it in detail.
>>
>> Regards,
>>
>> Tomeu
>>
>> --
>> «Sugar Labs is anyone who participates in improving and using Sugar.
>> What Sugar Labs does is determined by the participants.» - David
>> Farning
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
> --
>
> Marie von Ebner-Eschenbach  - "Even a stopped clock is right twice a day."



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning


More information about the Sugar-devel mailing list