[Standards-JIG] UPDATED: JEP-0030 (Service Discovery)
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
> - 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).
More information about the Standards