[JDEV] JEPs and Jabber Adoption

[Adrian Blakey]

Isn't this a case of "code wins"?

And couldn't a lesson be taken from the IETF's process?

If you propose a standard it should be accompanied by an unemcumbered 
reference implementation that we can all use/try/shake down for a while. 

Yeah maybe the best solution will not get out there - but something pragmatic 
will.

Adrian Blakey

On Thursday 26 June 2003 09:22 pm, Iain Shigeoka wrote:
> +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
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev