stpeter at jabber.org
Wed Jun 11 21:16:46 CDT 2003
Today Dave Smith and I had a conversation about the importance of
seeking and incorporating feedback from implementers of our protocols,
and of designing protocols that people actually want to implement. The
JSF does not exist to create protocols for the sake of protocols. A
beautiful protocol with no implementations is useless.
With that in mind, I'm wondering if we need to be more stringent about
initiating Last Calls. Right now a Council member proposes a Last Call
and some number or percentage of JSF members need to second the motion.
While this requires some level of support from active members of the
community, it doesn't include a "reality check" that the proposed
protocol will actually be implemented. To take an example (the example
that Dizzy brought up with me), I think we can ask some pointed
questions about JEP-0013 (Flexible Offline Message Retrieval). Is this
something that end users are begging for? Do the coders among us plan
to implement this protocol? If not, why are we pushing it forward? (I
ask these questions as co-author of the JEP.) It's easy to get caught
up in designing protocols, but we want to make sure that we're making
protocols that people want to use.
I think it would be really useful for JSF members to vote +1 on a Last
Call motion only if they intend to implement the protocol (either in an
open-source project or in a commercial product). If the protocol needs
to be implemented in both a server and a client, I think it would be
best to require at least two server developers and at least three
client developers to say that they plan to implement the protocol
before going to Last Call (same for components). For client-only
protocols (e.g., XHTML IM), we might require five client developers to
say that they plan to implement.
Obviously this is a much more stringent requirement than 5% of JSF
members voting +1 just because the JEP contains a pretty protocol. But
I think a reality check of this kind will help to ensure that JSF
protocols are really needed and wanted out there in the marketplace.
If this makes sense (and I think it does), I'd like to ask these hard
questions about JEP-0013 (it's always best to make your own proposal
the "guinea pig"):
1. Are there at least two server developers who will publicly state
that they plan to implement "Flexible Offline Message Retrieval"
as defined in JEP-0013? I know that there are representatives of
the following server developers on this list:
- jabberd project
- Jabber, Inc.
- Jive Software
- maybe more (if they're not members, they *should* be)
Do you guys need and want this protocol? Will you implement it in
2. Are there at least three client developers who will publicly state
that they plan to implement JEP-0013 in their clients? I know we
have plenty of client developers on this list. So how about it?
Will we see support for this JEP in Exodus, Psi, Nitro, MyJabber,
mov, Gabber, TipicIM or TipicME, etc.? (Assume that some servers
will implement it.)
Unless I get public commitments from people that they think this
protocol is needed and will be implemented, I will probably retract
this JEP or make it informational. The Jabber specs are busy enough
as it is, without adding protocols that no one will use.
More information about the Members