[standards-jig] JEPs and Jabber Adoption
thoutbeckers at splendo.com
Sun Jun 29 03:25:22 UTC 2003
David Waite <mass at akuma.org> wrote on 29-6-2003 5:16:29:
>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.
So do JEPs (the Jabber protocol)
>- the linux kernel does not have a standards organization behind it -
(exactly why I brought it up to compare it, there is no standards
organization with rules like ours behind it. So that's a strange point
>when you take the main kernel tree as a cross-section, it is ruled by
>dictatorship (although the dictator definitely is good at choosing
However, the dictator is far from all powerfull. So much in fact, you
could hardly call it a dictator. In fact, the dynamics behind it are
that of a selforganizing anarchic community (never noticed how everyone
just writes up patches all the time and submits them to world+dog? yet
they still end up with compliant goodworking systems). There's just a
clever man behind it that picks those dynamics up and makes a real good
branch out of it. Hardly a dictator.
>- changes in a linux kernel do not affect the ability of other users
>to communicate with your system (or rather, I should say 'working
Subsystems affect other subsystems, or even break them.
I'm not arguing that the development of the linux kernel and a more-
than-IM protocol and the software around it are exactly the same. The
requirments *are* somewhat different. However, the community behind
does have many simularities. There's a lot of energy and good will in
both. But because our requirments are different we try to shape those
forces in a different way, wich is very understandable. But I do think
too much of that energy is getting lost the way we do it now. Also,
there's seems to be some (I hope!) irritional fear that our community
posses none of those selforganising capabilities and thus needs big
brother JSF to hold hands every step. While, looking at the past, we've
already proven the opposite.
>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.
Those vendors sure did what you suggested. But did W3C allow them to?
Hell no. So what was the result like? Well, very good.. if you have
Microsoft stocks. W3C has learned from this and are doing better with
XHTML, will we? They too realised, we're not just making a standard
here, people are building these browsers and applications and they have
>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.
I agree, MUC is a nice example of how it could work, pub-sub however is
an example of where a lot of good will and effort has been smothered.
Many people tried to do work on this, but got blocked by the proces we
force upon it. Thankfully we'll still end up with something reasonable,
or even pretty good considering the idea is we can extend it later.
I still say, the way to determine wich of those viewpoints is good or
sufficiant should shift more towards useable implementations. (how
exactly doesn't matter that much to me). There will not be interop.
hell as a result of this, the community is mature enough to prevent
that. On top of that, once it's clear wich proposal is prefered (wich
will most likely be the one that almost everyone uses by then anyway),
the JSF will be able to make a very clear difference to everyone on top
of that. ACTIVE/FINAL still sounds very different from RETRACTED,
DEPRECATED and OBSOLETE. "You're still running that BETA of Exodus that
supports that DECPRECATED protocol? c'mon!!"
Software Engineer @ Splendo
More information about the Standards