[sugar] How do I connect to a Jabber server ?

[Morgan Collett]

On Tue, Aug 5, 2008 at 19:30, Mikus Grinbergs <mikus at bga.com> wrote:
> Morgan wrote:
>>> My _wish_ is simple:  I want a chance to contact (for Chat, or for
>>> collaboration) another XO at a different location.  Basically, for
>>> me to initiate that, that other XO's icon needs to be shown in my
>>> Neighborhood view.
>>
>> Therefore you (and the people you want to contact) need to be on a
>> community jabber server
>
> You are talking about how to *use* a jabber server once one is
> connected.  I do not *have* a connected jabber server.

It should *just work*. However there are many potential problems. You
might be able to help us detect problems we haven't triggered
ourselves, and by providing logs you can help us diagnose and
therefore fix the problem, if it is something we can fix.
Unfortunately there are many situations we can't fix, like a jabber
server not running - it's up to the admin of that server to rectify
that situation, and we are willing to provide assistance with that.

>> To see people from remote locations, you need to be on the same Jabber
>> server as they are.
>>
>> That requires:
>> * Internet access - via an Access Point, or over the mesh via a school
>> server, or over the mesh via a Mesh Portal Point XO which in turn has
>> access, or even via some dialup technology like bluetooth+GPRS.
>> * Network Manager to get an IP address
>> * A jabber server to be configured
>> * That server to be working
>> * Other people to be on the server.
>
> What I an aware of is:
>
>  (1)  Months ago, I would boot my XO, and other XO icons would show
>       up in my neighborhood view (from whatever jabber server I had
>       specified via sugar-control-panel).  Then "remote users"
>       stopped showing up (no matter which server I had specified).
>
>  (2)  I do not myself know enough about 'telepathy', etc., to be
>       able to figure out what is going wrong.  That is why I am
>       asking for assistance.

presenceservice.log and the output of olpc-netstatus should tell us
what was happening. You don't *need* to know much about the details,
but we will explain for all who are interested.

> [I'm a G1G1 user, and do not have a Mesh Portal Point to use, nor a
> school server.  Except for me not connecting to a jabber server, the
> internet works well for me.]

I listed possible use cases to illustrate how the system operates...

>> Connecting to an AP disables the mesh, so I don't see the value of
>> what you want. Turning off the mesh while you are connected to a mesh
>> channel would simply (in the proposal) turn the wireless radio off
>> completely, resulting in neither gabble nor salut able to operate.
>
> Then I believe the language being used is imprecise.  To me,
> "turning off the mesh" means turning off the __mesh__.  If what is
> actually being turned off is the __radio__, then call it "turning
> off the wireless radio".
>
> What I keep butting my head against is not being able to *control*
> what is going on.  In my mind a 'mesh' is one interface, and an 'AP'
> is another interface.  I would like to "turn off the mesh" when
> there are no local XOs, and no school server.  You are saying that
> the 'AP' would get turned off as well.  Not something I prefer.
>
>
>> Mikus, tickets and logs, logs and tickets.
>
> The last time I focused on connectivity was Apr/May.  What I
> concluded then was that my tickets got closed depending on the
> effect they had on the code -- *not* on whether I as a user could
> now experience consistent system behavior.

We do now have QA people who will try the situation out and see
whether the fault was fixed, and a process that involves their signoff
before bugs are closed.

> I'm willing to file a ticket when I see something happening -- such
> as an error when accessing a Jabber server (though one such ticket
> was closed as 'invalid' - because that particular server had not
> given the expected answer).  But it is difficult to decide what to
> ticket/log when I do not see something happening -- for instance,
> what if a connection to a Jabber server were never attempted by my XO?

We appreciate the tickets, even they do on occasion get closed as
Won't Fix, Works For Me, Invalid... That's no indication of your
ticket-filing skills. We fix the things we can fix, and if it's
something out of our control we need to remove it from our work
queues. If there's some other way to resolve the situation perhaps we
can do better about notifying others if their servers are down, and so
on.

The log files should tell us a lot about a given situation.
presenceservice.log tells us when gabble and salut were running, what
disconnected or failed to connect, what buddies were seen and so on.
For any presence-related failure, including not seeing any buddies on
your screen, presenceservice.log gives us an ability to diagnose the
failure. It might not give us enough information, and if there is
ultimately not enough information for us to know what failed we have
no choice but to close the bug in some way. Sorry.

> Besides, I post from home - where I do not have a wireless AP.  To
> try anything, I have to go somewhere else, where I do not have
> access to my notes, etc.  Not easy for me to record details.
> [You ask "which establishment provided the AP?"  Does it *really*
> make a difference to you whether it was an establishment on 1st
> street, or one on 6th street ???]

It doesn't make a difference to me, but perhaps there is some
restaurant chain providing hotspots that filters out the XMPP port or
something. I don't know, multiple bug reports from particular people
listing common details helps to track down some weird situations we
can't reproduce in any other way. I put that in just to convey that
providing specific information helps.

>> The mesh and the AP are mutually exclusive.
>>
>> gabble and salut are independent of the network topology.
>
> I'm sorry, but these memes have been said so many different ways
> that they no longer convey any information to me.  If taking down
> the mesh can take down the AP, how can they be exclusive?  If salut
> listens on the mesh, isn't that a dependence on there being a mesh?

No memes. Actual software components.

salut is not mesh-specific. It works on access points, ethernet* -
anything. It uses avahi to find people on your local network segment.

(* some network-manager work may be required to seamlessly use USB
ethernet for collaboration, I haven't tried.)

When salut is running, that does not mean that the mesh network is
active. It simply means that you are not on a jabber server, and
therefore the default is to advertise your presence on the local
network, whatever that may be, and display the presence of any other
XO-like buddies. If you are on an access point, then salut will
display the presence of any other Sugar users on that WLAN (who are
also running salut).

* gabble can run on the mesh, in the case of a schoolserver with an
active antenna.
* salut can run on the mesh.
* gabble can run on an AP, in the event of a schoolserver with an AP,
or an internet-accessible jabber server, etc.
* salut can run on an AP.

Regards
Morgan