[Foundation] My take on service discovery

Nicholas Perez nick at jabberstudio.org
Wed Nov 27 01:39:39 CST 2002

I think it is worthy to note that I am seeing a convergence of thoughts 
on dynamic router configuration. Earlier I was working on such an 
"internal protocol" when I was working on my jabber router 
implementation. And it dramatically hinged on disco being accepted. It 
really is the best way to probe unknown entities for /specific/ 
information. Right now, with browse being informational, people are left 
to their own devices on trying to interact with other systems. We need 
to keep the protocol clear of the eccentricities of implementations. 
Defining a Standards Track way of gathering information from unknown 
entities allows everyone to play nice, yet let everyone know what 
features make your entity stand out.

Robert Norris wrote:

>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
>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.

More information about the Members mailing list