[Standards-JIG] UPDATED: JEP-0030 (Service Discovery)
ian.paterson at clientside.co.uk
Fri Mar 19 11:18:36 UTC 2004
> > In the shorter term we need to define how disco#items results
> > may be structured into managable sizes.
> 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).
IMHO it would generally not be a good idea to use JIDs to implement
hierarchy. It must be possible to move items around within a hierarchy (or
add them to other hierarchies) without changing their unique IDs. (Otherwise
all external references to the items will be broken.)
There may be other sub-optimal ways of implementing hierarchy with JEP-30
that seem OK at first sight. IMHO the JEP should save implementers the
effort of thinking about this - and protect them from mistakes - by giving
one example of how sub-directories *can* be implemented. (In the future many
many people will implement this JEP.)
Chris Mullins wrote:
> While it's certainly true that the various jeps don't mandate disco
> to return (for example) a complete list of MUC rooms, this is how I
> interpret it. This is obviously how others (Ian, et al) are also
> interpreting them. If other behavior is to be expected in the
> high-load case, this behavior should be spelled out somewhere.
Yes. IMHO directory structure may not strictly be protocol, but it is
fundamental to discovery.
The JEP should at least mention that it is possible to return
sub-directories of items that ARE addressable as JIDs. I confess that until
Peter confirmed it was OK, I really wasn't sure if the *inexplicit*
intention of the authors was to limit sub-directories to items "associated
with the target entity but NOT addressable as JIDs".
Communication is difficult. We can't know the minds of all the readers. So
it is best to be explicit.
I am not suggesting we limit the wonderful generality of Disco. It's just
that another example or two will help open people's minds to what is
possible with it. :)
> 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...
Great idea. If you do agree to add an example to JEP-30 then that one would
add extra value. :)
More information about the Standards