[JDEV] JEPs and Jabber Adoption

[Dave Smith]

-----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
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE++6t0YNE3chVHHsMRAga0AJ4woxPae+xPTrBBt9UWrtNQn3lHEACdGzWD
WVpI5jc/gNw90CTrRtIy0NE=
=bDeG
-----END PGP SIGNATURE-----