[Foundation] motions

[Shawn Wilton]

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.
> 
> Thanks.
> 
> --stpeter
> 
> _______________________________________________
> Members mailing list
> Members at jabber.org
> http://mailman.jabber.org/listinfo/members