[standards-jig] Re: LAST CALL: Service Discovery (JEP-0030)

Robert Norris rob at cataclysm.cx
Wed Dec 4 22:41:45 UTC 2002

> The JEP as it stands is totaly geared toward a client/server dialog. It is
> not totaly adequate in the case of component/server or server/server dialog.

I disagree, simply because I have already implemented
component-component discovery. Disco is great for this case - it took me
around two hours to complete the implementation, and is very clean and

> I would like to have a way to distinguish between various orginator (client,
> component, server) and have rdifferent eplies sent out  for each requestor
> category. I don't know if this is putting adequately, but information
> returned by disco could be 'public' and available to any requestor, and some
> may be 'private' or for some defined JID's eyes only.

That should be handled by the entity responding to the disco request. If
the requesting JID is not allowed to know about a particular entity,
then the respondent should not mention it in the disco response.

This kind of control is implementation specific, and is firmly outside
the realm of discovery.

> One certainly understand that a component might for example be interrested
> in knowing detail about the session manager running on the server, whereas a
> client would not have to know about it. This was one of the deficiencies of
> earlier attempts at discovering services (agents, browse) and this is not
> corrected in the current disco proposal.

A disco#items query only returns the JIDs that the queried entity knows
about. This response has no information about the entity associated with
the JID. For example, I can ask a server what components it knows about,
and it will tell me, but I don't know anything about the type of those
components without asking them.

If a client isn't interested in information about a particular
component, then it shouldn't ask. Its that simple.

(Furthermore, from a clients perspective, the "server" and the "session
manager" are one and the same. Perhaps a better example would be of some

> Not having that kind of capability would lead to using different protocol
> for features discovery if one is programing for a client or for a
> component/server. My take is that should be in the core disco rather than
> being handled by an extension. Doing so would make disco the real
> 'extensible container' protocol it deserve to be.

I'm not convinced. I haven't seen any shortcomings in disco yet, and it
certainly fixes the problems that agents/browse had.


Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20021205/37f7f80a/attachment.sig>

More information about the Standards mailing list