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

[Morgan Collett]

Hi Mikus

On Tue, Aug 5, 2008 at 00:40, Mikus Grinbergs <mikus at bga.com> 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
(http://wiki.laptop.org/go/Community_Jabber_Servers)

> Currently, only icons from the LOCAL mesh to which I am connected
> will show up in my Neighborhood view.  My question in this topic is:
> "What do I need to do to have icons from REMOTE locations show up ?"

Connecting to an access point will let you see icons from the local
WLAN via telepathy-salut. This can include regular PCs running Sugar.

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 am particularly interested in was Eben's statement that the
> user could turn the mesh on/off with the icon in the Frame.  I'm
> getting much too much 'salut' - I'm hoping that "turning off the
> mesh" (*all* of its channels) would give more emphasis to 'gabble'.

salut may overwhelm a busy mesh network with many XOs. That would deny
service to gabble. Otherwise, gabble takes precedence and will connect
if it can.

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.

> --------
>>> Suddenly the communications link
>>> between the school and the internet fails.  If the kid happens to be
>>> within range of an alternate AP, does he have to do something
>>> manually (such as entering the name of a non-school Jabber server)
>>> to re-establish Jabber contact to the outside world ?

For the known future, school servers will not usually be public. Hence
"re-establish Jabber contact to the outside world" has nothing to do
with a school server.

>> But I think you're mixing up "connected to
>> a Jabber server / server-cloud" and "connected to an AP".
>
> I don't think I am.  When I go to someplace that has wireless, and
> check my XO, I'm seeing that it connects fine to websites (meaning
> that the AP must be working), but whenever I then do 'ps -A' I see
> 'salut' (meaning that 'gabble' must be giving up).

Yes, gabble must be giving up.

Mikus, tickets and logs, logs and tickets. Please. Anecdotes of it not
working are of marginal value and cannot help us debug. We need as
much detail as you can possibly give. Which servers did you try? Did
you do any other type of check to see if they were up - such as nc
<servername> 5222? presenceservice.log? telepathy-gabble.log? Which
establishment provided the AP? Can we do anything to detect if they
are filtering ports? Did you have to log on with some sort of portal
web page to get Internet access?

> Currently there is only a *single* field for specifying the <Jabber
> server> name (and I've tried many names) - so I expect that when the
> currently specified one is not working, the user has to manually
> enter the name of a different <Jabber server>.

Consider it a bug when a server is not working. There is no point in
failing over to other servers without user intervention.

The community jabber servers are for specific communities. If the
whole world joins, of course the server will be swamped and it will be
down for everybody.

> What my question dealt with was "how is use of the 'school server'
> as the <Jabber server> specified?"   [I have not seen an answer.]
>
>  -  If the kid has to manually enter an internet-resolvable name for
>     the 'school server', then obviously while the 'school server' is
>     down, the kid has to enter a different name to continue to use
>     Jabber.
>
>  -  But if the use of the 'school server' as __also__ the <Jabber
>     server> is *automatic* whenever the XO connects to the 'school
>     server', then my question is "When the <Jabber server> at the
>     school fails, HOW does the XO know to start instead using the
>     specified "Jabber server name" for Jabber-type connections?"

It is specified in the same field as for any other jabber server.
However, the kid simply clicks "Register" on the home menu, and the XO
registers with the school server on the network, if there is one,
which automatically populates the jabber server field, so there is no
"manually enter an internet-resolvable name for the 'school server'".

There is no failover. The school server is supposed to work, and keep
on working. Using a different jabber server is a choice, and is
outside of the scope of the infrastructure of a school deployment.
Non-school Jabber servers should be considered to be populated with
completely random adults and not kid friendly. There is no monitoring,
and the servers are completely controlled by unknown people.

Our top priority is making school deployments work, via the school
server, with "a handful of kids under a tree" ad hoc collaboration
over the mesh network as the second most significant use case.

> [What lay behind my question was the suspicion that while the XO had
> a working mesh, and was vigorously trying to reach a 'school server'
> (using that server's mesh-resolvable name), it was giving "short
> shrift" to any 'gabble' attempts to reach (through the AP) the
> <Jabber server> whose name had been specified in the Control Panel.]

The mesh and the AP are mutually exclusive.

gabble and salut are independent of the network topology.

gabble-over-mesh and gabble-over-AP are the priority, while salut is
the fallback, although salut connects before gabble, and then
disconnects as soon as gabble gets a connection. gabble has
exponential backoff in retrying, to a maximum of 5 minutes. So once
gabble *can* connect, it may be 5 minutes before it retries.

On a mesh with a schoolserver, salut is kept off for 2 minutes while
gabble is tried, to try to prevent saturating the network when there
are large numbers of XOs.

Regards
Morgan