[Foundation] Motion to propose JEP-0030 (Service Discovery) to council

[johannes.wagener at gmx.net]

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 
children.

> 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 
op...

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:
http://skabber.rudbek.com/iq_browsing.png

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.

groupchat conmponent
for example if conference.jabber.org would return <ns>muc:createroom</ns>
i could simply create a room by clicking in the namespace.

conference room
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.

br
Edrin

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
> components:
> 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.
> 
> pgm.
> 
> 
> 
> 
> 
> _______________________________________________
> Members mailing list
> Members at jabber.org
> http://mailman.jabber.org/listinfo/members
>