[standards-jig] Re: Versioned Namespaces

Thomas Muldowney temas at box5.net
Thu May 8 16:22:19 UTC 2003


Just as a note to this thread, I poked council about this.  If you want
to watch the conversation subscribe to council.  It's slow moving but
I'll get my spurs out (go Spurs!)

--temas


On Thu, 2003-05-08 at 11:14, Evan Prodromou wrote:
> >>>>> "JK" == Jacek Konieczny <jajcus at bnet.pl> writes:
> 
>     JK> The poit is, that experimental specs should not be used any
>     JK> more, when the final spec is available. At least unitl the
>     JK> final spec is implemented.
> 
>     JK> Namespace versioning seems a very nice solution to me. Every
>     JK> jabber developer will notice when his software should be
>     JK> updated. And if he doesn't do that the experimental
>     JK> implementation will not break anything else.
> 
> +1
> 
> Thank you for such a clear summary.
> 
> I think most of the counterarguments against versioned namespaces are
> misplaced emotional responses: frustration with some players' practice
> of implementing experimental protocols, then expecting them to stay
> stable, and complaining if they don't. I can definitely see why this
> is undesirable.
> 
> But building support for change into the protocol definition process
> is, IMHO, a Good Thing. The burden on the JEP author is _extremely_
> low, and the advantage of specifying incompatibility is very high.
> 
> Jabber software is, fundamentally, communication software. That means
> that there are many implementation of the protocol, and many
> installation of those implementations. All of them happen to share the
> same Jabber network (hooray for that), which means that if any
> software uses older protocols, everyone on the network has to deal
> with it.
> 
> It would be nice if, as a protocol changed, all implementors would
> instantaneously implement the new version, and all users of the
> implementations would instantaneously upgrade their
> software. Overnight, all instances of the older version of the
> protocol would disappear from the network.
> 
> But I don't think that the real world works like that, and I don't
> think it's a good idea to base assumptions on that scenario.
> 
> ~ESP




More information about the Standards mailing list