[Foundation] Motion to propose JEP-0030 (Service Discovery) to council
johannes.wagener at gmx.net
johannes.wagener at gmx.net
Mon Nov 25 11:21:09 CST 2002
I do also think that the problem #1 and #3 can be fixed simply (if they are even
problems, because the namespaces of the children are optional!!!)
simply make it optional for components to return also the <ns/>or children of the
children they link to.
It is not necessary for ppl that browse around to already know the features of the
> For example, to find out about a text conferencing room (ie, what features
> it supports), I should query the room, and not the server.
yes, and indeed this is no problem:
-> browsing to the groupchat component should return
1. all rooms (children it has)
2. namespaces/features it supports itself (i.g. iq:time, create-chatroom)
that is both done with iq:browsing!
-> browsing to a room itself should return
1. all folk that is inside (flirt at conference.jabber.org/girl1)
2. namespaces/features it supports itself, in this case for example join-room, become
this is what browsing is doing already, just consider that the <ns/> and children of the
children are only optional, *like a link on a webpage*
here is a sample how i integrated it in my client:
If the developer of the new MUC would bring a bit more order and logic
(namespaces/features returned when browsing to a room...) in stuff returned when
browsing to a room/the groupchatcomponent itself, i could easily add a doubclick
support to create a room, too.
for example if conference.jabber.org would return <ns>muc:createroom</ns>
i could simply create a room by clicking in the namespace.
for example if jdev at conference.jabber.org would return <ns>muc:joinroom</ns>
i could simply join the room by clicking in the namespace.
On 25 Nov 2002 at 7:17, Peter G. Millard wrote:
> [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
> 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.
> 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.
> Members mailing list
> Members at jabber.org
More information about the Members