[Foundation] Re: Members digest, Vol 1 #365 - 16 msgs

Jean-Louis Seguineau /EXC/TEC jean-louis.seguineau at antepo.com
Wed Nov 27 13:26:20 CST 2002

This is an interresting try. The question boils down to knowing wether the
protocol must support a given implementation of a server, or wether a server
must implement a protocol.

Although I perfectly see the interest of having a dynamic protocol to allow
a server to discover at run time what services there is, and make it
available to its client, I am affraid the disco protocol as it stands is far
for being ready for prime time.

In the end do we want a protocol extension that would allow anybody to build
something on top of it, or do we want just a jabber2 compliant protocol ?


----- Original Message -----
> Message: 2
> Date: Wed, 27 Nov 2002 09:49:44 +1100
> From: Robert Norris <rob at cataclysm.cx>
> To: members at jabber.org
> Subject: [Foundation] My take on service discovery
> Reply-To: members at jabber.org
> --82I3+IH0IqGh5yIs
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> I really didn't want to contribute to this debate (especially as its not
> really the appropriate forum), but I thought that since I put forward
> the motion, it might be useful if people understood why I want it.
> jabberd2 (when released) will have the ability to bring components
> online dynamically - that is, without having to restart the server or
> edit configuration.
> In order to get the information about the new component in to the
> agents/browse/disco list, the session manager needs to know that the
> component has come online.
> For disco, this is dead simple - the router (that the component
> connected to) simply informs the SM (via an internal protocol) that a
> new component comes online. The SM the JID to the disco list, and
> clients then know about it.
> For agents/browse, it becomes far more complex. Because the router/SM
> only know the JID of the new component, they have no way to find out the
> additional information they require (name, type, supported namespaces,
> etc) to build an agents/browse entry.
> The only solution to this is to have the SM query the component, or to
> have the component push the information to the SM. Both of these options
> require component support, which means that existing components cannot
> be entered into an agents/browse list. Of course, the server config can
> be statically updated, but this loses the benefits of dynamic
> components.
> Disco is the clear winner for this application, because it seperates the
> childs metadata from the parent.
> Please don't reply to this saying that the issue of legacy components is
> not important, or there's some other way to do it - this isn't the
> appropriate forum. If you want input in the jabberd2 feature set and
> architecture, please post to jabberd at jabberstudio.org.
> Rob.
> --=20
> Robert Norris                                       GPG: 1024D/FC18E6C2
> Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/

More information about the Members mailing list