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

[David Van Assche]

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.

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)

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.

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....

kind regards,
David Van Assche

On Sun, Nov 8, 2009 at 12:36 PM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:

> 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
>



-- 

Stephen Leacock<http://www.brainyquote.com/quotes/authors/s/stephen_leacock.html>
- "I detest life-insurance agents: they always argue that I shall some
day
die, which is not so."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20091109/e9dc5339/attachment.htm