On Sat, Nov 7, 2009 at 17:40, David Van Assche <[email protected]> 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 <[email protected]> wrote: >> >> On Wed, Nov 4, 2009 at 13:16, Benjamin M. Schwartz >> <[email protected]> wrote: >> > Martin Langhoff wrote: >> >> On Tue, Nov 3, 2009 at 9:54 PM, David Van Assche <[email protected]> >> >> 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 >> [email protected] >> 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 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
