[standards-jig] JEPs and Jabber Adoption
thoutbeckers at splendo.com
Sat Jun 28 22:26:56 UTC 2003
Thomas Muldowney <temas at box5.net> wrote on 29-6-2003 0:00:07:
>I had a long reply to this previously but the webmail client I was
>using at the time ate it. My arguments came down to a few points
>though. First and foremost we have to keep interoperability in mind.
>Many of your examples just dont' make sense because they do not effect
>interoperability they are all about choices to base systems.
Not quite, take for example the schedular example. This greatly effects
other portions of the kernel.
>filesystem example, just because I use ext3 doesn't mean I can't send a
>file to someone using XFS.
Well, it also means your linux box in some cases can't read my firewire
HDD if I bring it along to you unless it supports all those systems.
Eventually, during the proces of implementation, some will prove
superiour and remain, and some will fade away into history. In the
meanwhile though, we do have useable systems.
>If we wanted to compare we'd need to look at
>API or ABI disscusions. Those can be bitter and long.
And we get different competing API's out of it (look at XML for
example, or SOAP vs. XML-RPC).
>Another of your
>examples is the desktop split for *nix systems. Well, they have
>something like the JSF, it's called freedesktop.org, and they have long
>drawn out discussions to find a single interoperable standard for many
>desktop services. Interoperability takes time and effort, but the
>rewards are well worth it.
And they work the exact opposite way of here. They make something,
implement it, then later look what's best to use or what's the best way
Rather then *having* GNOME and KDE to play with (yes sir, and their
different APIs), would you rather be *talking* about the perfect unix
desktop with me now?
>Reading your suggestions about moving stuff to draft can only make me
>think that our rules should be s/experimental/draft. What you advocate
>seems to change nothing. We'd just end up putting the red warning on
>draft jeps instead of experimental jeps.
I'm not at all suggesting that we just go ahead and make every proposed
a DRAFT immidiatly. I'm proposing that we move ahead ideas -solutions
for a problem- that are technically sound, even if there are competing
*different* solutions -different *ideas*- to the same problem.
In the EXPERIMENTAL fase the JEP author will receive feedback of the
community to resolve bugs and issues with his proposals, and the
community can suggest enhancments to the protocol that *complement* the
idea. (It's *mostly* for the author of the JEP to determine wether
these are within the scope of the JEP, and they can always be made into
seperate JEPs if he thinks not).
If these are solved, I see no reason to block the JEP any further. But
currently, that's more rule than exception, because community and
council members have competing *ideas* to solve the problem.
Filetransfer is the ultimate example for this. Why not IBB? Oh it
should be message not iq. Why not Jidlink? Oh there's an extra
roundtrip. Why not DTCP? Oh, it should be based on something else.
These are not bugs or quirks in the "experimental" protocol. Different
*ideas* should compete in implementation, NOT experimental theoretical
>I still feel my comments stand about the s-jig itself and the council
>needing to participate more. I looked at the numbers for this month
>and out of 257 members just roughly 15% have posted on the list. Sure
>they may get tired of having to argue the fine points, I know I want
>to walk away almost every week, but we have to argue the fine points
>so that we have a solid _interoperable_ system.
Well here's an idea (it might not be true, can't speak for those
people), people get tired of reviewing JEPs of reviewing, helping find
bugs, and suggesting additions to an idea, because once they're done
with that their efforts go to waist cause someone else decides it's a
bad idea or his/hers is better, locking the whole process.
>I'm not saying I want things to
>move slowly, I think it's possible to do this rapidly, but it takes
>effort from everybody, council, s-jig, and anyone else that cares.
Software Engineer @ Splendo
More information about the Standards