[Foundation] Motion to propose JEP-0030 (Service Discovery) to council

Peter G. Millard me at pgmillard.com
Mon Nov 25 08:17:31 CST 2002


[Lots of stuff about how iq:browse is good snipped]

There are several problems with browse currently (from a technical
standpoint) that make it very difficult to implement in servers and
components:
1) A single result set gives you capabilities (supported namespaces) as well
as a list of child entities and THOSE supported namespaces.
2) It is limited by the <ns> element, and is not generic enough.
3) A parent node must either "know" or cache all of the browse info for all
of it's children (since child nodes are reported back w/ the parent). This
means that a parent node must always know all of the possible information
about all children, or be able to cache that info so it can report back.

For example, to find out about a text conferencing room (ie, what features
it supports), I should query the room, and not the server.

As you suggested, we could fix #2 by simply extending the DTD, but that does
nothing to address #1 and #3. Those problems are fundamental to the way the
protocol was designed & implemented.

While disco may seem "harder" to implement in a client because it requires
multiple round trips... it is the only possible solution to have browsing
requests scale, be implementable, and be possible for services which could
possibly have 10's of thousands of child nodes.

pgm.








More information about the Members mailing list