shawn at black9.net
Wed Jun 11 21:26:21 CDT 2003
I'm working on my new client now and I would like to add this feature to
it. So I will +1 this JEP. *Will* I implement this? Yes. *When* I
will implement this, is still uncertain. The New client, though a piece
of coding comparable to the work of gods ;-), is coming along slowly for
the lack of time I have, but I will be adding this feature I figure in
the next 3 months.
For the record we have needed this sort of accountability for awhile.
Peter Saint-Andre wrote:
> 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.
> - Antepo
> - Jive Software
> - i3Connect
> - Tipic
> - maybe more (if they're not members, they *should* be)
> Do you guys need and want this protocol? Will you implement it in
> your servers?
> 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.
> Members mailing list
> Members at jabber.org
More information about the Members