[standards-jig] JEP-0102

Nick nick at jabberstudio.org
Thu Jul 3 03:44:19 UTC 2003


This thought follows exactly what I was saying in another thread on 
putting into place the concept of stages for experimental jeps. So when 
JEP-XYZ reaches Theta stage for example and is seeking implementation 
from the implementors group, people know the protocol is useable and 
changes to it will be slight to account for technical flaws. The idea 
of a JEP going from Experimental to Draft with no formal steps 
inbetween doesn't give people and idea on how much experimenting is 
left.
-- 

Nicholas Perez
Email: 	nick at jabberstudio.org
Jabber:	nickperez at jabber.org
Home:	303.759.0574




On 2003.07.02 11:02, Peter Ronez wrote:
> > Or do you fear that these experimental implementations will stay
> > forever, even after the JEP gets advanced to draft status, and these
> > preliminary implementations would make jabber unstable or
> inconsistent?
> 
> OK, I think some people are missing the point. It's great if people
> provided
> feedback and implementations to the JEP writers and what not. However,
> the
> current mindset of how people want the JEP process to work is not
> scalable, in
> my opinion.
> 
> Imagine if Jabber becomes wildly successful tomorrow (fingers crossed
> ;). If
> that's the case, their would be an absolutely flurry of JEPs from
> companies and
> people alike trying to get their say in what the protocol will look
> like next.
> And so the Jabber.org people go to work, pump out the JEPs, a couple
> of vocal
> client writers say "yeah we need this!" and then all of a sudden its
> part of
> the standard. This is one of many scenarios.
> 
> A more likely scenario is that Jabber.org wouldn't be able to keep up
> with
> those kinds of demands, and I don't think they need to. Every
> extension to
> Jabber does not need the seal of approval from Jabber.org. However,
> the larger
> and core pieces of the Jabber framework out to be approved by them so
> that
> there can be a consensus.
> 
> Take the issue about Avatars. Even though the JEP has been removed and
> is not
> likely to be recommended by the Jabber.org staff, it shouldn't stop
> client
> developers from implementing the feature. The people in that position
> can
> always come up with their own JEP and post it on their websites for
> other
> client developers to interop.
> 
> In a way, I can see Jabber.org's JEPs as the top-tier of Jabber
> specifications.
> If Jabber.org says you need to implement this feature in this way,
> then it
> should behoove all developers to do it in that manner. However, a
> second and
> third-tier organizations (popular clients) can have their own list of
> JEPs that
> are perhaps not pertinent to everyone but nonetheless useful to other
> client
> developers.
> 
> I just want to say that I do feel the pain of the client developers. I
> too am
> working on a client, and yes, it does suck not to have everything laid
> out
> perfectly for me. However, I need to strike a balance here. Yes, I may
> need to
> use some JEPs that aren't finalized, but I'll probably try to use only
> the ones
> that are stable and not likely to change much. I could be wrong and it
> could be
> painful to upgrade my client code later, but I'm sure its easier than
> upgrading
> the protocol ;)
> 
> 
> 
> The implementations should mirror the protocol, not the other way
> around.
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 



More information about the Standards mailing list