+100. 'nuff said. Thats me as a client author, and me as a council member. I'd like nothing more than to see this finished before a new council is elected.
pgm. 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
