One area I'm a little unsure about is the network connectivity (ie, how sugar presence interfaces with sugar presence service backend. Presumably it just uses NM and launched telepathy's RequiredConnection dbus pythong binding. What's interesting, reading over the developer's manual is that there are 3 ways of pretty much automating connection and presence, on demand, automatically, and on request. The difference is not entirely obvious immediately, but it does show that what sugar presence is currently doing could be done much more easily, and probably more efficiently by telepathy directly.<br>
<br>It would also open up better mnagament of VOIP, multi cast video (via libjingle) and the use of other connection managers (I dont know if this is really needed or wanted, but the possibility is there)<br><br>The question now, is where to start... I mean... are we going to redo all of sugar.presence and sugar presence service, and let telepathy handle all/most of the connectivity/presence/collaboration? Right now, the only thing that is pure telepathy is the dtube collaboration, which to me is also the part that seems to work the best.<br>
<br>So where to do we start, who is gonna volunteer to do this. I am volunteering to help, but a lot of it goes above my head. I know the theory quite well, but I'm afraid of touching  a lot of that code....<br><br>kind regards,<br>
David Van Assche<br><br><div class="gmail_quote">On Sun, Nov 8, 2009 at 12:36 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;">
<div class="im">On Sat, Nov 7, 2009 at 17:40, David Van Assche <<a href="mailto:dvanassche@gmail.com">dvanassche@gmail.com</a>> wrote:<br>
> Hi,<br>
>    So I was looking over the code with some of the #telepathy guys who are<br>
> also under the impression that sugar.presence code could be causing many of<br>
> the collab problems. Main issue is redundancy of code... a lot of what is<br>
> happening in sugar.presence already happens in telepathy (actually there are<br>
> even comments in sugar.presence code stating this) but until we know to what<br>
> level activities are using sugar.presence, we can't really do anything...<br>
> since activities would break, I guess we'd need to know what in the<br>
> sugar.presence modules is being really actively used to migrate to MC 5...<br>
> and give a warning or something, or keep some kind of sym links to the old<br>
> functions... I dunno, kinda above my level of expertise...<br>
<br>
</div>Yes, info about presence is duplicated in several places. Any bugs at<br>
each layer can cause the unreliability we see.<br>
<br>
Regards,<br>
<font color="#888888"><br>
Tomeu<br>
</font><div><div></div><div class="h5"><br>
> regards,<br>
> David van Assche<br>
><br>
> On Fri, Nov 6, 2009 at 2:02 PM, Tomeu Vizoso <<a href="mailto:tomeu@sugarlabs.org">tomeu@sugarlabs.org</a>> wrote:<br>
>><br>
>> On Wed, Nov 4, 2009 at 13:16, Benjamin M. Schwartz<br>
>> <<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>> wrote:<br>
>> > 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>><br>
>> >> 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<br>
>> > change<br>
>> > in how the client software is organized.  Neither regression nor<br>
>> > improvement in wireless network performance should occur.<br>
>><br>
>> 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<br>
>> it.<br>
>><br>
>> But in any case, we need to do some exploration now before we can<br>
>> discuss it in detail.<br>
>><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>
><br>
><br>
><br>
> --<br>
><br>
> Marie von Ebner-Eschenbach  - "Even a stopped clock is right twice a day."<br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="h5">«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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><br><a href="http://www.brainyquote.com/quotes/authors/s/stephen_leacock.html" target="_blank">Stephen Leacock</a>  - "I detest life-insurance agents: they always argue that I shall some day die, which is not so."