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

[johannes.wagener at gmx.net]

ah, and if you need restrictions: simply do 
xmlns="jabber:iq:browse#info", that´s basically the same as in disco, 
but the stuff will continue to be compatible.

On 25 Nov 2002 at 18:21, johannes.wagener at gmx.net wrote:

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