[Standards-JIG] UPDATED: JEP-0030 (Service Discovery)
me at pgmillard.com
Tue Mar 16 19:54:35 UTC 2004
Ian Paterson wrote:
> If a MUC server has 1000 rooms and an average of 10 users entering each room
> per hour. If each MUC client allows its user to choose from a list of room
> names and occupants before he/she enters a room. Then that will result in a
> total of 10 thousand disco#items requests, plus 10 million disco#info
> requests per hour!
Clients just don't do this kind of thing in the real world (at least for MUC
they don't). My client may get a list of rooms, and send a disco#info to each
room (1001 IQ roundtrips), but it surely should never query further. In
addition, the server would probably not ALLOW me to get a list of users in each
room if I'm not in the room. In addition, other logic can prevent the
"mass-flood" of disco#info queries from a client. For example, in the Exodus
browser, it ONLY fetches disco#info for each child entity if there are 20 items
or less. So when I browse to ietf.xmpp.org, I only see the jids, not the fact
that each one is a TC room.
> If JEP-30 does not allow some carefully controlled exceptions, then simple
> everyday functionality, like we see in this example, will require new JEPs
> that duplicate much of Disco.
So far in the real world, we have yet to see this happen. Jabber has always used
the design rules of "solve the problems we know about, not the ones we don't."
For example, if a system allows a HUGE result to be given to the user, perhaps
that service should use the jabber:iq:search protocol instead of providing
drill-down capabilities via jabber:iq:disco.
> There seems to be agreement that "parents can know something more than just
> the JID of a child node" (i.e. the name), as long as "implementations don't
> assume it will always be there."
The name attribute is OPTIONAL. Implementations which provide disco results to a
user should always provide a fallback if name is not there.
> IMHO we need to define under exactly which (exceptional) circumstances JEP
> writers should be allowed to specify that "parents can know more than just
> the JID". Only in these cases could the extra information be returned in a
> 'verbose' disco#items result (or something like it):
Here are the two rules you can live by:
- "Parent" entities MAY provide a name for each child object, it is not
- ALL OTHER meta-data about a "child" entity should be provided in the
disco#info result from the child entity itself.
More information about the Standards