Isn't this a case of "code wins"? And couldn't a lesson be taken from the IETF's process?
If you propose a standard it should be accompanied by an unemcumbered reference implementation that we can all use/try/shake down for a while. Yeah maybe the best solution will not get out there - but something pragmatic will. Adrian Blakey On Thursday 26 June 2003 09:22 pm, Iain Shigeoka wrote: > +1 > > IMO, I think much of the reason is the JEP process has cost us the > 'throw-away-ability' of the normal 'implement in multiple ways and > choose the best' strategy common in less structured open source. JEPs > are approached more as, 'let's create the best and only protocol that > should solve problem x'. So rather than 5 different bytestream > protocols, we've struggled and so far failed to pass the 'One'. There > are positive and negatives to it. Is it better to have a year or more > of multiple protocols that all do the same thing, or a year of arguing > and no protocol at all? :) > > I agree though that something -- hell, anything -- should be passed so > we can get FT implemented already. I believe we're at the point where > the council just needs to choose an arbitrary solution and get us > moving... Oh council? > > -iain > > On Thursday, Jun 26, 2003, at 19:27 US/Pacific, Dave Smith wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > +2 > > > > On Thursday, Jun 26, 2003, at 19:45 America/Denver, Paul Curtis wrote: > >> I normally avoid all of the conflicts surrounding JEPs, as I am > >> rather content to implement than to propose. However, in my one year > >> of active participation in the Jabber community, I have watched as > >> proposals for much needed features have been sidelined, retracted, or > >> left for dead because of lack of community concensus. > >> > >> The point of a community is community, and not competition. In > >> addition, the JEP process, and the XMPP protocol itself, makes it > >> easy to implement a feature and extend it later. Isn't that one of > >> the touchstones of the protocol itself? "Extensible" is part of the > >> name ... it's not just a word or phrase, but rather a methodology for > >> this protocol. > >> > >> So, where am I going with this? I have watched a single, much needed, > >> and frequently requested feature get "reinvented" three times in the > >> space of a year. Rather than trying to make it perfect from the > >> start, let the community agree on the current proposed enhancements > >> as a starting point. This will give the client developers and the > >> users something that works, while not perfect for every need, will > >> meet the needs of 90% of the user base. > >> > >> I stand in an untenable position: having promoted Jabber and XMPP > >> internally to my company, I have to explain that a fundamental > >> feature that every legacy IM system has is absent in Jabber and XMPP. > >> The community needs to support this feature to even be on the same > >> playing field as the "competition" that is already out there. > >> > >> What is this feature? File transfer. Currently, the community needs > >> to find any major flaw with the existing JEPs mentioned below, and > >> forward them all as a group to last call. These four JEPs will give > >> the Jabber/XMPP users what they really want. > >> > >> Now, are these JEPs perfect? Probably not. But, then again, neither > >> was SMTP (RFC 822 & 2822). There are many extension RFCs to SMTP to > >> enhance its usability and to add features that are not necessarily > >> used by many systems in the "mainstream". The JEPs I'm speaking about > >> are: > >> * JEP-0042 Inband Bytestreams (the lowest common denominator for > >> file transfers) > >> * JEP-0065 SOCKS bytestreams > >> * JEP-0096 Stream Initiation > >> * JEP-0096 File Transfer Initiation > >> > >> With these four, the Jabber community can cover that 90% of the user > >> base. Without them, I'll have to wait out yet another file transfer > >> JEP (or JEPs) to be dissected and argued over. If that is the case, > >> then I can't continue to be a proponent of the Jabber community, > >> because the community is not acting in its best interest. > >> > >> We, as a community, have lost active participants over the course of > >> the year because of petty arguing. We, as a community, cannot afford > >> to lose any more (or anyone at all) at this point. XMPP stands to > >> take over as a "standard" IM protocol. We need to have this > >> capability ironed out and solid when that happens. > >> > >> Let's take these four JEPs, remove any major flaws, add any major > >> omissions, and finalize them now. I can't stand to wait for another > >> complete restart on file transfer, and I'm getting less and less > >> willing to extoll the virtues of the protocol and community when > >> something like this cannot be agreed upon. > >> > >> paul > >> > >> _______________________________________________ > >> jdev mailing list > >> [EMAIL PROTECTED] > >> http://mailman.jabber.org/listinfo/jdev > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.1 (Darwin) > > > > iD8DBQE++6t0YNE3chVHHsMRAga0AJ4woxPae+xPTrBBt9UWrtNQn3lHEACdGzWD > > WVpI5jc/gNw90CTrRtIy0NE= > > =bDeG > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > jdev mailing list > > [EMAIL PROTECTED] > > http://mailman.jabber.org/listinfo/jdev > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
