[Foundation] Re: JEP-0030 (Service Discovery) not ready

Jean-Louis Seguineau /EXC/TEC jean-louis.seguineau at antepo.com
Tue Nov 26 13:57:14 CST 2002


Well, at least this may be the real start of a discussion about this
subject. There is a world of difference between this JEP and what as been
achieved for MUC. To say the least, I completely understand the position of
Johanes, as putting that kind of unfinished extension out would somewhat
look like a diktat.
In a way, there isn't much in this new JEP that cannot be achieved in using
jabber:iq:browse properly (in a structured way that was never described in
anaything about browse).
On the other hand, this is also true that browse was implemented in such a
hurry that it did not anticipate scalability issues, and limitations of its
own construct (having only <ns> as child of item is a good example).

PSA at some point wanted more challenge after the extraordinary exercise on
MUC, I think he has another task up to his ability. Make JEP0030 into an
acceptable proposal. This obviously includes going through all the phases of
finding out what the "business requirement" are. This is realy what is
lacking in this paper. Why do we want a new JEP, just because we want to
code differently, or because we want it to serve a purpose ? Nothing in this
JEP provides a good reply as to what purpose this protocol extension is
geared.

Jean-Louis


----- Original Message -----
> From: johannes.wagener at gmx.net
> To: members at jabber.org
> Date: Mon, 25 Nov 2002 18:21:09 +0100
> Subject: Re: Re: [Foundation] Motion to propose JEP-0030 (Service
Discovery) to council
> Reply-To: members at jabber.org
>
> 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.





More information about the Members mailing list