[JDEV] JEPs and Jabber Adoption
Paul Curtis
pcurtis at terrapin.com
Thu Jun 26 20:45:41 CDT 2003
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
More information about the JDev
mailing list