John,<br><br>I am sure 20 laptops will melt down a channel currently. But in this case, the 20 are already turned on and running salut, right?<br>My point is:<br>If you turn on one laptop running salut (it is the only one turned on for a while) can it connect to a school server (even while  running salut)? If so it can abandon mDNS in favor of XMPP after connected to gabble.<br>
The next laptop will do the same.<br>If you don't turn many XOs on at the "same time", you won't have salut preventing gabble to work.<br>My fear is that we are complicating things unnecessarily.<br><br>
<div class="gmail_quote">On Thu, Feb 14, 2008 at 5:42 PM, John Watlington <<a href="mailto:wad@laptop.org">wad@laptop.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Ricardo,<br>
    That is the current situation, and the chatter generated by Salut<br>
multiplied by mesh multicast<br>
really does prevent laptops from connecting through gabble.   We did<br>
a recent test here where<br>
20 laptops really melted down a single channel.<br>
<br>
wad<br>
<div><div></div><div class="Wj3C7c"><br>
On Feb 14, 2008, at 2:39 PM, Ricardo Carrano wrote:<br>
<br>
> I am not sure I was clear. I meant: maybe it is not necessary to<br>
> turn it (salut) off _while_ trying to connect to gabble. If<br>
> connected to gabble, then stop salut.<br>
> Wouldn't this simplify matters?<br>
><br>
> On Thu, Feb 14, 2008 at 3:44 PM, Ricardo Carrano<br>
> <<a href="mailto:carrano@ricardocarrano.com">carrano@ricardocarrano.com</a>> wrote:<br>
> (e) make salut less chatty during this period (instead of stopping<br>
> it).<br>
> But I don't know if this is possible or how to do it. So it maybe<br>
> not a valid suggestion.<br>
><br>
> But ...<br>
><br>
> I think we have a time sensitive problem. Salut clogs the network<br>
> if there are many XOs running it. So, if you think of a scenario<br>
> where many XOs are _not_ turned on at the same time (or  within a<br>
> certain time window) each XO will have an opportunity to switch to<br>
> gabble without the need to turn salut off. The network will be<br>
> naturally salut free.<br>
><br>
> Maybe  we don't need to turn salut off while trying to connect to<br>
> gabble.<br>
><br>
><br>
><br>
> On Thu, Feb 14, 2008 at 3:19 PM, John Watlington <<a href="mailto:wad@laptop.org">wad@laptop.org</a>><br>
> wrote:<br>
><br>
> On Feb 14, 2008, at 11:52 AM, Jim Gettys wrote:<br>
><br>
> ><br>
> > On Thu, 2008-02-14 at 16:58 +0200, Morgan Collett wrote:<br>
> >> We're testing patches to Presence Service to not start salut (or<br>
> stop<br>
> >> it) for a while to give gabble a chance to connect to the<br>
> >> schoolserver.<br>
> >><br>
> >> However, Daf came across what was a very minor problem which<br>
> becomes<br>
> >> more serious in light of this change.<br>
> >><br>
> >> Many activities are calling PS get_preferred_connection() to<br>
> interact<br>
> >> directly with the appropriate Telepathy Connection Manager,<br>
> which was<br>
> >> required in the past before we expanded Presence Service's<br>
> >> management of<br>
> >> setting up channels for activities.<br>
> >><br>
> >> However, during the period when we stop salut to let gabble try to<br>
> >> connect, this call fails as there is no running plugin in PS. If an<br>
> >> activity is launched during this time (and there's no particular<br>
> >> UI to<br>
> >> show this other than no buddies in mesh view) and it makes this<br>
> >> call in<br>
> >> __init__ as most of them do, then it will crash with a gray screen.<br>
> >><br>
> >> This affects: Calculate, Chat, Pippy, Record, Web and Write (of the<br>
> >> activities we bundle) and potentially other non-bundled activities.<br>
> ><br>
> > Ouch...<br>
> ><br>
> > Seems like this is something we're going to have to fix pretty<br>
> quickly<br>
> > no matter what.<br>
> ><br>
> >><br>
> >> Our options are:<br>
> >><br>
> >> (a) Touch all these activities now and port them to the newer<br>
> cleaner<br>
> >> API offered by PS/Sugar<br>
> ><br>
> > How big are the diffs?  Does this simplify the code?<br>
> ><br>
> >> (b) Don't do #6299 for Update.1, but do it and (a) for Update1.1<br>
> ><br>
> > This would be pretty much immediately, anyway.<br>
> ><br>
> >> (c) Find some way for the call to get_preferred_connection to fail<br>
> >> gracefully (We can't think of one so far)<br>
> >> (d) Make a UI change to let the children know not to launch<br>
> >> activities<br>
> >> during this time period\<br>
><br>
> (d) might be the simplest to implement in the required time frame.<br>
><br>
> > Let me ask a different question: what happens to activities already<br>
> > running which are running shared?  Are they going to fail?<br>
> > Presumably,<br>
> > yes....<br>
><br>
> It sounds like any activity trying to share until either gable<br>
> connect to a server<br>
> or gives up and starts salut is going to crash.  This either happens<br>
> on boot or<br>
> when a user manually switches networks.<br>
><br>
> wad<br>
><br>
><br>
> _______________________________________________<br>
> Devel mailing list<br>
> <a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
> <a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
><br>
><br>
> _______________________________________________<br>
> Devel mailing list<br>
> <a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
> <a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
<br>
</div></div></blockquote></div><br>