Presence service bugs/enhancements

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 23 Oct 2007 at 07:55:57 -0400, Kim Quirk wrote:
> > 1. The presence service should detect more efficiently the internet
> > connectivity and switch to gabble when appropriate(4193)

As I commented on the bug, we need debug logs - this should have worked, and
without logs we can't know why it didn't.

> > 2. In link-local XOs are seen in neighbor view but cannot be shared with.
> > Sometimes they are not connected to the mesh anymore, but still present. In
> > some such cases the avahi-browse cannot resolve the services of the
> > corresponding XO. This is high priority but i dont have a log file in a
> > blocking case, although i have experienced it in build617(4402)

Sjoerd is the expert for this one.

> > 3. Ability to switch from gabble to salut manually using the options:
> > auto,salut,gabble(4403)

As I commented on the bug, I'd like some more idea what the
requirements are for this.

> > 4. Ability to keep an activity alive when passing from salut to gabble and
> > vice versa. This can occur automatically when internet connectivity is
> > dynamically lost or recovered(4404)

As commented:

This is difficult, and can't be fixed purely within PS - activities will
need to handle the switchover themselves, since we don't and can't know how
to resynchronize arbitrary activities (the activity can't assume that everyone
migrates at the same time). I don't think this is feasible for 1.0.

> > 5. In gabble, the public IP must be available in the buddy list, or at
> > least be accessible through the jabber server upon request(4405)

As I commented, the private addresses are going away soon too - we only
have them because some activities (Read) haven't been ported to use
Tubes for collaboration yet (bug filed). The only reason they're visible in
the dev console is that it's meant to give a complete picture of what the PS is
thinking, so it should expose all information the PS knows about.

The XO might not *have* a public IP, might not be usefully reachable at
its public IP, (e.g. when behind NAT), and so on, so this is not
generally useful information for PS to provide.

> > 6. The jabber servers should be switchable(to change from one to the
> > other) in a neater way then accessing the config file and rebooting. This
> > can probably be invoked by sending smth like ......xmlns:stream="
> > http://etherx.jabber.org/streams" to="jabber.laptop.org"....as i noticed
> > in the log files.  If it is simple to apply, can you describe how it can be
> > done properly?(not on trac)

No, you can't send a new <stream:stream> element to the server to
magically turn it into a different server :-) Gabble needs to be told to
open a new TCP connection to the new server and do XMPP over that, and
drop its old connection. This is entirely possible; Gabble already supports
connecting to many servers simultaneously, if this is ever needed.

It would be possible to add API to the Presence Service to drop its
connection to the current server and connect to a different server. What
are the requirements for this task? Is there a UI requirement that we should
be supporting? I'd guess that this would be part of the same UI that
handled switching between Gabble and Salut?

Parts of the PS theoretically support connecting to arbitrarily many Telepathy
connections (any combination of Gabble and Salut), but sharing becomes
awkward in that case (you can't yet share across multiple servers, and
sharing the same activity across XMPP and link-local at the same time is
a minefield). Activities involving XOs from multiple servers are currently
planned for 1.1; it's too early to say whether that's overly optimistic.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFHHfQhWSc8zVUw7HYRAig+AJ0XzTzFGnx5MeOpbAZ5/sosbGl3uwCgwS0y
BoVS+nQu5DrEYehaQpMUD7k=
=HJhs
-----END PGP SIGNATURE-----