Re: Presence service bugs/enhancements
>
> > > 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 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?
This would be the requirement CP1.3 ("Set which jabber/school server"), right?
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Presence service bugs/enhancements
On Tue, Oct 23, 2007 at 02:16:18PM +0100, Simon McVittie wrote: > > > 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. See the comments in the bugreport Sjoerd -- No use getting too involved in life -- you're only here for a limited time. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Presence service bugs/enhancements
Ar 23/10/2007 am 07:55, ysgrifennodd Kim Quirk: > Thanks for putting these all together, Yani. > > Dafydd and Simon - can we discuss these and the new mesh protocol at the > 12:30pm edt meeting today? I think some of these issues are supposed to be > addressed with the more robust protocol. Sure, we can join in. -- Dafydd ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Presence service bugs/enhancements
-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 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- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Presence service bugs/enhancements
Thanks for putting these all together, Yani. Dafydd and Simon - can we discuss these and the new mesh protocol at the 12:30pm edt meeting today? I think some of these issues are supposed to be addressed with the more robust protocol. Thanks, Kim On 10/23/07, Giannis Galanis <[EMAIL PROTECTED]> wrote: > > Simon, > > The following are the current bugs/enhancements regarding the presence > service. They are listed from high to low priority with their corresponding > trac number. > > 1. The presence service should detect more efficiently the internet > connectivity and switch to gabble when appropriate(4193) > > 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) > > 3. Ability to switch from gabble to salut manually using the options: > auto,salut,gabble(4403) > > 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) > > 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) > > 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) > > Thanx > > yani > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Presence service bugs/enhancements
Simon, The following are the current bugs/enhancements regarding the presence service. They are listed from high to low priority with their corresponding trac number. 1. The presence service should detect more efficiently the internet connectivity and switch to gabble when appropriate(4193) 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) 3. Ability to switch from gabble to salut manually using the options: auto,salut,gabble(4403) 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) 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) 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) Thanx yani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
