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

Ben Schumacher ben at blahr.com
Tue Nov 26 13:55:22 CST 2002


-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE949GoUpoGqensAXIRAlKwAJ9Mqonz/CrThsr7yB7m+AIsI4nriACgsAC1
U+MGEwAhsSStMM++ML6Gsnc=
=nep7
-----END PGP SIGNATURE-----




More information about the Members mailing list