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

Richard Dobson richard at dobson-i.net
Tue Nov 26 18:26:08 CST 2002

I wrote my message in support of disco not against it as the tone of 
your message implies, I was just stating what I think is the reason 
these few voices are against disco (they dont want to have to write yet 
more browsing/disco code into their clients), also its fine for new 
components not to support browse, but clients will certainly have to 
until all components are rewritten (which could be quite a few months) 
to maintain compatibility, there is also the problem of 
clients/components that are no longer maintained that people still use 
and have no alternative for.


On Tuesday, November 26, 2002, at 07:55  pm, Ben Schumacher wrote:

> Hash: SHA1
> Richard Dobson wrote:
> | I think the disco namespace in its current form, is much better than
> it used
> | to be (havent looked at it in ages) and it is now not really very 
> far away
> | from what browse is anyway so am not sure what the fuss is about, I 
> think
> | what this boils down to is that people are going to have to support 
> two
> | different methods of browsing in their clients/servers/components 
> but dont
> | want to have to.
> Why would you support two different methods? I see no reason to 
> continue
> to support browse, in fact, any new component I write will not. There 
> is
> no reason to support two different methods, because there is only one
> method that has been decided by the council to be part of the protocol
> moving forward. The informational iq:browse JEP simply documents
> something that was used at one point in time, but which has obvious
> issues. Trying to "fix" the issues in iq:browse is exactly the point of
> the standards track service discovery JEP. Reusing the same namespace
> only complicates the issue, and doesn't add any value. If I were a
> client author, after the JEP was accepted, I would remove iq:browse
> support and plug in iq:disco support. While it might take a while for
> some components to catch up, it would ultimately serve the community 
> better.
> iq:browse will probably be deprecated when disco is advanced by the
> council. Components and clients MAY continue to support it, but it is
> not required. Ultimately, it is up to the council to decide what's best
> for the protocol, and it is up to the community to vote on council
> members who we think will best represent our views. That's the way the
> system works. If you have a technical problem with service discovery,
> please feel free to share with the rest of us, and the council members
> will surely take that into account when the JEP goes to a vote. If,
> however, your only objection is simply the fact that you don't want to
> do the work to implement the protocol then I suggest you suck it up and
> deal with it. While this might save you x number of hours of work, it
> ultimately damages the protocol and will probably mean more work down
> the line for developers as they continually have to work around the
> mistakes of the past. (Think Y2K.)
> Cheers,
> bs.
> Version: GnuPG v1.2.0 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> iD8DBQE949GoUpoGqensAXIRAlKwAJ9Mqonz/CrThsr7yB7m+AIsI4nriACgsAC1
> U+MGEwAhsSStMM++ML6Gsnc=
> =nep7
> _______________________________________________
> Members mailing list
> Members at jabber.org
> http://mailman.jabber.org/listinfo/members

More information about the Members mailing list