-----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
