[Standards-JIG] UPDATED: JEP-0030 (Service Discovery)

Peter Millard me at pgmillard.com
Thu Mar 18 15:50:47 UTC 2004


Ian Paterson wrote:
> In general, IT users demand two ways to find nodes. Sometimes they want to
> explore/browse a structured directory, other times they want to search (the
> Windows Explorer is an example). So IMHO we need two solutions to this
> problem.
>
> - In the medium term we need the new general search JEP that people have
> already mentioned.

Why do we need a new JEP??? JEP-55 defines the jabber:iq:search protocol which
should be adequate for ALL possible needs (since you can leverage x-data in this
protocol). Why do people think jabber:iq:search is deprecated??? This does NOT
appear anywhere in the JEP. It's information. period.

> - In the shorter term we need to define how disco#items results may be
> structured into managable sizes.

This very much seems like an implementation detail. For example, when I
disco#items the HUGE MUC service, I could get back 20 categories of rooms where
that muc implementation has some kind of hierarchy defined (possibly something
like: comp.cpp at muc.foo.com). As you implied in your post the node attribute can
be used to drill down through a hierarchy. Again, this is already possible, but
just has never been spelled out. This DOES NOT belong in a JEP IMO (it's not
protocol). This kind of information should go into an implementation guide.

FWIW, the same sorts of problems apply to large Pubsub implementations (JEP-60).

The examples you proposed using the node attributes to allow folks to drill down
to find the room they want seems like a great solution to me. If an impl doesn't
want to impose a hierarchy, it can simple alphabetize them. So my first disco
result returns: a, b, c, d, etc.... When I select the "A" node, I get maybe 10
more groups, etc...

This type of operation uses the existing protocol (no changes), and makes the
user experience very good (IMO).

pgm.






More information about the Standards mailing list