[Foundation] motions

Peter Saint-Andre stpeter at jabber.org
Fri Jun 13 12:15:51 CDT 2003


OK, given that it seems some server developers want this functionality 
and at least one or two client developers say they plan to implement it,
I'll go ahead with the Last Call.

Was this useful? Should we add this step to the process?

Peter

On Thu, Jun 12, 2003 at 09:02:58AM -0600, Craig Kaes wrote:
> Jinc will be needing this functionality over the next year, particularly for
> its wireless clients.
> 
> --C
> 
> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter at jabber.org]
> Sent: Wednesday, June 11, 2003 8:17 PM
> To: members at jabber.org
> Subject: [Foundation] motions
> 
> 
> 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
> _______________________________________________
> Members mailing list
> Members at jabber.org
> http://mailman.jabber.org/listinfo/members

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php




More information about the Members mailing list