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