Serious side effect of #6299 (silencing salut so gabble can connect)

[Ricardo Carrano]

I am not sure I was clear. I meant: maybe it is not necessary to turn it
(salut) off _while_ trying to connect to gabble. If connected to gabble,
then stop salut.
Wouldn't this simplify matters?

On Thu, Feb 14, 2008 at 3:44 PM, Ricardo Carrano <carrano at ricardocarrano.com>
wrote:

> (e) make salut less chatty during this period (instead of stopping it).
> But I don't know if this is possible or how to do it. So it maybe not a
> valid suggestion.
>
> But ...
>
> I think we have a time sensitive problem. Salut clogs the network if there
> are many XOs running it. So, if you think of a scenario where many XOs are
> _not_ turned on at the same time (or  within a certain time window) each XO
> will have an opportunity to switch to gabble without the need to turn salut
> off. The network will be naturally salut free.
>
> Maybe  we don't need to turn salut off while trying to connect to gabble.
>
>
>
> On Thu, Feb 14, 2008 at 3:19 PM, John Watlington <wad at laptop.org> wrote:
>
> >
> > On Feb 14, 2008, at 11:52 AM, Jim Gettys wrote:
> >
> > >
> > > On Thu, 2008-02-14 at 16:58 +0200, Morgan Collett wrote:
> > >> We're testing patches to Presence Service to not start salut (or stop
> > >> it) for a while to give gabble a chance to connect to the
> > >> schoolserver.
> > >>
> > >> However, Daf came across what was a very minor problem which becomes
> > >> more serious in light of this change.
> > >>
> > >> Many activities are calling PS get_preferred_connection() to interact
> > >> directly with the appropriate Telepathy Connection Manager, which was
> > >> required in the past before we expanded Presence Service's
> > >> management of
> > >> setting up channels for activities.
> > >>
> > >> However, during the period when we stop salut to let gabble try to
> > >> connect, this call fails as there is no running plugin in PS. If an
> > >> activity is launched during this time (and there's no particular
> > >> UI to
> > >> show this other than no buddies in mesh view) and it makes this
> > >> call in
> > >> __init__ as most of them do, then it will crash with a gray screen.
> > >>
> > >> This affects: Calculate, Chat, Pippy, Record, Web and Write (of the
> > >> activities we bundle) and potentially other non-bundled activities.
> > >
> > > Ouch...
> > >
> > > Seems like this is something we're going to have to fix pretty quickly
> > > no matter what.
> > >
> > >>
> > >> Our options are:
> > >>
> > >> (a) Touch all these activities now and port them to the newer cleaner
> > >> API offered by PS/Sugar
> > >
> > > How big are the diffs?  Does this simplify the code?
> > >
> > >> (b) Don't do #6299 for Update.1, but do it and (a) for Update1.1
> > >
> > > This would be pretty much immediately, anyway.
> > >
> > >> (c) Find some way for the call to get_preferred_connection to fail
> > >> gracefully (We can't think of one so far)
> > >> (d) Make a UI change to let the children know not to launch
> > >> activities
> > >> during this time period\
> >
> > (d) might be the simplest to implement in the required time frame.
> >
> > > Let me ask a different question: what happens to activities already
> > > running which are running shared?  Are they going to fail?
> > > Presumably,
> > > yes....
> >
> > It sounds like any activity trying to share until either gable
> > connect to a server
> > or gives up and starts salut is going to crash.  This either happens
> > on boot or
> > when a user manually switches networks.
> >
> > wad
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel at lists.laptop.org
> > http://lists.laptop.org/listinfo/devel
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080214/c866e1cc/attachment.html>