[standards-jig] JEPs and Jabber Adoption

David Waite 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 
accurate:
- 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 
competent advisors).
- 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.

-David Waite




More information about the Standards mailing list