[standards-jig] JEPs and Jabber Adoption

Tijl Houtbeckers 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. 

>Take the
>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 
to integrate. 

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 
discussion. 

>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.
>
>--temas


-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list