Yes, i have seen this ticket in the past. To detect whether an XO is actually there or not, is a simple task to accomplish, and I am currently working on a simple script that will give a list of the properly connected XOs, along with the temporarily disconnected.
<br><br>It is a very useful idea to display this information in the neighbor view, in terms of a dotted line, or a grey color perhaps.  The problem is that the bugs are dealt with according to priority, and generally enhancements although very practical, can cause  other bugs, or take several builds until they work properly. 
<br><br>Since we are in "code freeze", a quick solution must be implemented to solve the current situation, ie that it takes up to an hour for a disconnected xo to dissapear(just reported as #4735).<br><br>yani<br>
 <br><br><div class="gmail_quote">On Nov 7, 2007 5:49 PM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</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;">
<div class="Ih2E3d">> > 1. We need to fix the timeout for icons to disappear. Can we try Guillaume's<br>> > patch?<br>><br>> I hope so. I have a tarball with the patch, but I'm still waiting for<br>
> Update.1 approval (it's unclear whether I can build RPMs for Joyride<br>> before I get Update.1 approval or not). If you're at 1CC, could you please<br>> annoy the ApprovalForUpdate people in person until they either look at their
<br>> bugs, or confirm whether I'm still allowed to build RPMs in Koji?<br><br></div>Just a mention, since this thread is getting a lot of attention. There<br>is an added visual element which should be in play here, according to
<br>the design.  There should be an intermediate state before XOs<br>disappear from the view, as outlined in:<br><br><a href="http://dev.laptop.org/ticket/3657" target="_blank">http://dev.laptop.org/ticket/3657</a><br><div>
<div></div><div class="Wj3C7c"><br><br>> > 2. We need to be able to restart PS. As you say this is not possible, but if<br>> > we restart sugar will PS restart as well?<br>><br>> Yes, that's right (the D-Bus session bus will exit, which causes
<br>> D-Bus services like PS to exit too unless they've specifically asked not to).<br>><br>> I see you assigned the bug about "need to be able to cope with PS restarts" to<br>> yourself. Unless you're planning to implement the necessary Python code
<br>> in sugar.presence yourself, please don't.<br>><br>> I don't think it's feasible to implement correct handling of PS restarts in<br>> sugar.presence for Update.1, so unless the release engineering team
<br>> specifically tell me to, I won't be addressing that bug until a later<br>> release.<br>><br>> > 3. We need to force gabble to run. We have several instances of 4193 (almost<br>> > all XOs connected to schoolserver,AP are running salut). Or at least to
<br>> > force trying to connect to jabber server.<br>><br>> Please see my comments on #4193 regarding steps to take to debug (I think<br>> it's #4193 I commented on - I can't remember bug numbers, and Trac is
<br>> down at the moment).<br>><br>> In summary:<br>><br>> * try resolving the server with "getent hosts <a href="http://jabber.laptop.org" target="_blank">jabber.laptop.org</a>"<br>> * try pinging it with "ping 
<a href="http://jabber.laptop.org" target="_blank">jabber.laptop.org</a>"<br>> * try connecting via TCP with "telnet <a href="http://jabber.laptop.org" target="_blank">jabber.laptop.org</a> 5222"<br>>   (type "hello" and press Enter, if all goes well you should get disconnected
<br>>   with an error message that mentions "XML not well formed")<br>><br>> If any of these steps fail, Gabble won't be able to connect either, and<br>> there's nothing Gabble can do about it - talk to the Network Manager
<br>> maintainer instead, since that's the component responsible for getting<br>> network connectivity and DNS on the XO.<br>><br>> If you check the Gabble log you'll probably find that Gabble is trying
<br>> to connect, but failing because either it can't resolve<br>> <a href="http://jabber.laptop.org" target="_blank">jabber.laptop.org</a> in DNS, or it can't get a TCP connection there. That was my<br>> diagnosis of two of the cases you mentioned in your bug with 3 sets of logs
<br>> (which may have been #4193?). In the third case it looked as though you hadn't<br>> waited long enough for the log to indicate success or failure.<br>><br>> > 4. The process of trying to connect to the jabber server, is done by
<br>> > telepathy-gabble, or by the presence<br>><br>> Depends what you mean. The Presence Service is responsible for choosing when<br>> to try to connect (at which time it calls the Connect() D-Bus method<br>
> on Gabble), but it's Gabble that actually opens a TCP socket to the Jabber<br>> server and tries to talk to it. You can see this in the PS log, for<br>> instance:<br>><br>> 1194431620.966651 DEBUG s-p-s.telepathy_plugin:
 <ServerPlugin object at<br>> 0x85f1e14 (telepathy_plugin+TelepathyPlugin at 0x82c8fb0)>: connecting...<br>> 1194431620.967008 DEBUG s-p-s.telepathy_plugin: <ServerPlugin object at<br>> 0x85f1e14 (telepathy_plugin+TelepathyPlugin at 0x82c8fb0)>: Connect()
<br>> succeeded<br>><br>> (note that "Connect() succeeded" is a bit misleading - it just means<br>> that the connection manager has said "OK, I'll try", rather than that it<br>> has actually been able to connect.)
<br>><br>> In the telepathy-gabble log you'll then see something like this:<br>><br>> ** (telepathy-gabble:25330): DEBUG: do_connect: calling lm_connection_open<br>> Going to connect to <a href="http://olpc.collabora.co.uk" target="_blank">
olpc.collabora.co.uk</a><br>> Trying <a href="http://195.10.223.134" target="_blank">195.10.223.134</a> port 5222...<br>> ** (telepathy-gabble:25330): DEBUG: tp_base_connection_change_status:<br>> was 4294967295, now 1, for reason 1
<br>> ** (telepathy-gabble:25330): DEBUG: tp_base_connection_change_status:<br>> emitting status-changed to 1, for reason 1<br>><br>> (here status 4294967295 means "haven't tried to connect yet", status 1 means
<br>> "connecting", reason 1 means "by user request")<br>><br>> If the TCP connection succeeds, in the telepathy-gabble log you'll see:<br>><br>> Connection success.<br>> SEND:<br>
> - -----------------------------------<br>> <?xml version='1.0' encoding='UTF-8'?><br>> - -----------------------------------<br>><br>> Some XMPP handshaking will follow.<br>><br>> Finally, when Gabble has finished doing its initial setup on the
<br>> connection, it will signal that it's become connected:<br>><br>> ** (telepathy-gabble:25330): DEBUG: tp_base_connection_change_status:<br>> was 1, now 0, for reason 1<br>> ** (telepathy-gabble:25330): DEBUG: tp_base_connection_change_status:
<br>>  emitting status-changed to 0, for reason 1<br>><br>> (here status 0 means "connected")<br>><br>> and the Presence Service will receive the StatusChanged signal via D-Bus:<br>><br>> 1194431621.473412
 DEBUG s-p-s.telepathy_plugin: <ServerPlugin object at<br>> 0x85f1e14 (telepathy_plugin+TelepathyPlugin at 0x82c8fb0)>: connected<br>><br>>     Simon<br>> -----BEGIN PGP SIGNATURE-----<br>> Version: GnuPG 
v1.4.6 (GNU/Linux)<br>> Comment: OpenPGP key: <a href="http://www.pseudorandom.co.uk/2003/contact/" target="_blank">http://www.pseudorandom.co.uk/2003/contact/</a> or <a href="http://pgp.net" target="_blank">pgp.net</a>
<br>><br>> iD8DBQFHMaGcWSc8zVUw7HYRAjPOAKDuLi+Vp04s8aGs9pbGQ8Lkr8fwzgCgxaza<br>> ipqZMRnw9vKHTYTJT+e96qg=<br>> =vEu4<br>> -----END PGP SIGNATURE-----<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>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></div></div></blockquote></div><br>