[JDEV] JEPs and Jabber Adoption

Iain Shigeoka iain at jivesoftware.com
Thu Jun 26 23:22:12 CDT 2003


+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
>> 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-----
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>




More information about the JDev mailing list