[standards-jig] JEPs and Jabber Adoption
mass at akuma.org
Sun Jun 29 03:16:29 UTC 2003
Tijl Houtbeckers wrote:
> Can you imagine linux kernel hackers debating for years about what new
> scheduler to use, and have nothing beyond very experimental work
> happing cause some fictional "linux council" would refuse to advance
> one beyond experimental?
> Ofcourse not.. we have a whole bunch of schedulers outthere now.
> They're not "experimental" either, they are real implementations,
> outthere, and being used. Wich one will make it into the official
> kernel branch? And maybe some that won't will still be maintained cause
> they perform better under special circumstances. You could compare that
> to advancing to "ACTIVE" or "FINAL".
All the comparisons to the linux kernel on this thread are simply not
- variances of the linux kernel share a large amount of code-base; they
are not independent from-scratch implementations.
- the linux kernel does not have a standards organization behind it -
when you take the main kernel tree as a cross-section, it is ruled by
dictatorship (although the dictator definitely is good at choosing
- changes in a linux kernel do not affect the ability of other users to
communicate with your system (or rather, I should say 'working changes')
Think if the W3 had decided that they would promote every web browser
vendor to develop versions of HTML based on their customer needs? Of
course all the vendors did this originally; they definitely don't need
the overhead of a standards process in order to do so. What a standards
body brings to the table is interoperability and conformance.
The JSF will not be able to conquer large-scale issues until it finds a
way to organize all the strong and different viewpoints of its members
into a single process. This is not always going to be possible to do by
having someone take control of the reins, such as it was with multi-user
chat and is currently with pub-sub.
Which of the many file-transfer-related JEPs will win out? I don't know;
there isn't even an overall set of requirements that these 'next
generation' data transfer protocols are setting out to meet. In my
personal opinion, HTTP-based out of band transfer is still the winner
because it has existing, deployed support across several different
clients and vendors.
When we started the JSF, we first had a process where JIGs were formed
to tackle particular problems; this did not work out well because there
wasn't enough participation to move standards forward once they were
weighted down with process. If we are moving to a membership system that
requires a certain level of participation, perhaps we could and should
try the old JIG system again.
Without requirements, the only way I see file transfer becoming standard
is if there is a majority of the membership backing it in lieu of the
other available options. I think we all know this will never, ever
happen - if it meets all the requirements for certain authors, it will
be deemed too complex for implementation; if it is simple, it will be
deemed either too inefficient or not enough of a step forward from the
existing out-of-band mechanism to warrant doing it.
More information about the Standards