You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Daniel Rall <dl...@finemaltcoding.com> on 2002/02/26 18:23:01 UTC
frozen specification
josh lucas <jo...@stonecottage.com> writes:
> Daniel Rall wrote:
> >
>> "Rick Johnston" <RR...@symantec.com> writes:
>>
>> > I guess this is one of the problems of working with a frozen
>> > standard. The rest of the world doesn't necessarily care whether
>> > people can use that standard.
>>
>> Yeah, I may end up forking away from the standard myself.
> My only word of caution on the possible forking away from the standard
> is that you have to be careful not to break backwards compatability.
> Many people are using xml-rpc in a variety of languages and for the
> 'main' Java implementation to break things would be very bad.
>
> Obviously the plan isn't to break things but I just wanted to throw this
> out there.
Right -- that the XML-RPC specifiction is frozen is a huge mistake.
AFAIK, an HTTP/1.1 server is fully backwards compatible with HTTP/1.0,
and offers many enhancments that would be directly applicable to any
data tunnelled through it (such as XML-RPC). It makes zero sense to
not support these enhancements when support can be added without
breaking backwards compatibility. The server should speak 1.1 to
clients that announce support for it, and 1.0 for clients that do not.
- Dan
Re: frozen specification
Posted by josh lucas <jo...@stonecottage.com>.
Daniel Rall wrote:
>
> josh lucas <jo...@stonecottage.com> writes:
>
> > Daniel Rall wrote:
> > >
> >> "Rick Johnston" <RR...@symantec.com> writes:
> >>
> >> > I guess this is one of the problems of working with a frozen
> >> > standard. The rest of the world doesn't necessarily care whether
> >> > people can use that standard.
> >>
> >> Yeah, I may end up forking away from the standard myself.
>
> > My only word of caution on the possible forking away from the standard
> > is that you have to be careful not to break backwards compatability.
> > Many people are using xml-rpc in a variety of languages and for the
> > 'main' Java implementation to break things would be very bad.
> >
> > Obviously the plan isn't to break things but I just wanted to throw this
> > out there.
>
> Right -- that the XML-RPC specifiction is frozen is a huge mistake.
> AFAIK, an HTTP/1.1 server is fully backwards compatible with HTTP/1.0,
> and offers many enhancments that would be directly applicable to any
> data tunnelled through it (such as XML-RPC). It makes zero sense to
> not support these enhancements when support can be added without
> breaking backwards compatibility. The server should speak 1.1 to
> clients that announce support for it, and 1.0 for clients that do not.
>
yup. I'm totally +1 on backwards-compatible enhancements.
josh
Re: frozen specification
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"John Wilson" <tu...@wilson.co.uk> writes:
> ----- Original Message -----
> From: "Daniel Rall" <dl...@finemaltcoding.com>
>
>> Right -- that the XML-RPC specifiction is frozen is a huge mistake.
>> AFAIK, an HTTP/1.1 server is fully backwards compatible with HTTP/1.0,
>> and offers many enhancments that would be directly applicable to any
>> data tunnelled through it (such as XML-RPC). It makes zero sense to
>> not support these enhancements when support can be added without
>> breaking backwards compatibility. The server should speak 1.1 to
>> clients that announce support for it, and 1.0 for clients that do not.
>
> I don't speak for Dave Winer but this is my understanding of the
> situation: Dave (or his company) owns the trademark XML-RPC. Dave (or his
> company) owns the copyright to the XML-RPC spec. Dave will let people use
> the XML-RPC trademark if they implement the spec (this is logically a bit
> difficult as the spec is unclear in many places and contradicts the XML spec
> in at least one place). Dave will let people make changes to and build
> extensions on the XML-RPC spec as long as they don't call it XML-RPC.
Right, I read this last time you posted it too. ;-)
(And thanks for that, I was not aware of the information at the time
or your original post.)
> The reality is that many implementations make quiet extensions to the spec
> (for example the Apache XML-RPC implementation handles the Latin-1 character
> set, the spec (almost) requires ASCII). As long as they don't make a fuss
> about this then Dave leaves them alone. Dave gets unhappy if people do high
> profile things like implement <null/>.
I have no personal interest in null. I'm interested in a RPC server
with reasonable performance when handling large quantities of data.
> Dave, like all of us, is not 100% consistent in the judgements he expresses.
> However he has been remarkably consistent in maintaining the above position
> for a couple of years now.
>
> The Apache project has a high profile and a well deserved reputation for
> respecting intellectual property. It appears to me that you should consider
> carefully before adding extension to your XML-RPC implementation.
My last message never indicated I was going to do this with the Apache
implementation.
However, I may end up modifying (at least) the server code to support
HTTP/1.1 in addition to supporting the primitive XML-RPC specification
(togglable). I will definitely contribute any such changes back to
the ASF, inclusion of which will be dealt with as per the Jakarta
decision guidelines <http://jakarta.apache.org/site/decisions.html>.
For a quick HTTP/1.1 start, the bundled proxy Servlet would plug into
Tomcat for Chunk Transfer Coding support (I know that Catalina has
full support for this).
> I do sympathise most deeply with your frustration, however;)
Thanks John.
- Dan
Re: frozen specification
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"John Wilson" <tu...@wilson.co.uk> writes:
> ----- Original Message -----
> From: "Daniel Rall" <dl...@finemaltcoding.com>
>
>> Right -- that the XML-RPC specifiction is frozen is a huge mistake.
>> AFAIK, an HTTP/1.1 server is fully backwards compatible with HTTP/1.0,
>> and offers many enhancments that would be directly applicable to any
>> data tunnelled through it (such as XML-RPC). It makes zero sense to
>> not support these enhancements when support can be added without
>> breaking backwards compatibility. The server should speak 1.1 to
>> clients that announce support for it, and 1.0 for clients that do not.
>
> I don't speak for Dave Winer but this is my understanding of the
> situation: Dave (or his company) owns the trademark XML-RPC. Dave (or his
> company) owns the copyright to the XML-RPC spec. Dave will let people use
> the XML-RPC trademark if they implement the spec (this is logically a bit
> difficult as the spec is unclear in many places and contradicts the XML spec
> in at least one place). Dave will let people make changes to and build
> extensions on the XML-RPC spec as long as they don't call it XML-RPC.
Right, I read this last time you posted it too. ;-)
(And thanks for that, I was not aware of the information at the time
or your original post.)
> The reality is that many implementations make quiet extensions to the spec
> (for example the Apache XML-RPC implementation handles the Latin-1 character
> set, the spec (almost) requires ASCII). As long as they don't make a fuss
> about this then Dave leaves them alone. Dave gets unhappy if people do high
> profile things like implement <null/>.
I have no personal interest in null. I'm interested in a RPC server
with reasonable performance when handling large quantities of data.
> Dave, like all of us, is not 100% consistent in the judgements he expresses.
> However he has been remarkably consistent in maintaining the above position
> for a couple of years now.
>
> The Apache project has a high profile and a well deserved reputation for
> respecting intellectual property. It appears to me that you should consider
> carefully before adding extension to your XML-RPC implementation.
My last message never indicated I was going to do this with the Apache
implementation.
However, I may end up modifying (at least) the server code to support
HTTP/1.1 in addition to supporting the primitive XML-RPC specification
(togglable). I will definitely contribute any such changes back to
the ASF, inclusion of which will be dealt with as per the Jakarta
decision guidelines <http://jakarta.apache.org/site/decisions.html>.
For a quick HTTP/1.1 start, the bundled proxy Servlet would plug into
Tomcat for Chunk Transfer Coding support (I know that Catalina has
full support for this).
> I do sympathise most deeply with your frustration, however;)
Thanks John.
- Dan
Re: frozen specification
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Daniel Rall" <dl...@finemaltcoding.com>
To: <rp...@xml.apache.org>
Sent: Tuesday, February 26, 2002 5:23 PM
Subject: frozen specification
[snip]
> Right -- that the XML-RPC specifiction is frozen is a huge mistake.
> AFAIK, an HTTP/1.1 server is fully backwards compatible with HTTP/1.0,
> and offers many enhancments that would be directly applicable to any
> data tunnelled through it (such as XML-RPC). It makes zero sense to
> not support these enhancements when support can be added without
> breaking backwards compatibility. The server should speak 1.1 to
> clients that announce support for it, and 1.0 for clients that do not.
Dan,
I don't speak for Dave Winer but this is my understanding of the
situation: Dave (or his company) owns the trademark XML-RPC. Dave (or his
company) owns the copyright to the XML-RPC spec. Dave will let people use
the XML-RPC trademark if they implement the spec (this is logically a bit
difficult as the spec is unclear in many places and contradicts the XML spec
in at least one place). Dave will let people make changes to and build
extensions on the XML-RPC spec as long as they don't call it XML-RPC.
The reality is that many implementations make quiet extensions to the spec
(for example the Apache XML-RPC implementation handles the Latin-1 character
set, the spec (almost) requires ASCII). As long as they don't make a fuss
about this then Dave leaves them alone. Dave gets unhappy if people do high
profile things like implement <null/>.
Dave, like all of us, is not 100% consistent in the judgements he expresses.
However he has been remarkably consistent in maintaining the above position
for a couple of years now.
The Apache project has a high profile and a well deserved reputation for
respecting intellectual property. It appears to me that you should consider
carefully before adding extension to your XML-RPC implementation.
I do sympathise most deeply with your frustration, however;)
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: frozen specification
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Daniel Rall" <dl...@finemaltcoding.com>
To: <rp...@xml.apache.org>
Sent: Tuesday, February 26, 2002 5:23 PM
Subject: frozen specification
[snip]
> Right -- that the XML-RPC specifiction is frozen is a huge mistake.
> AFAIK, an HTTP/1.1 server is fully backwards compatible with HTTP/1.0,
> and offers many enhancments that would be directly applicable to any
> data tunnelled through it (such as XML-RPC). It makes zero sense to
> not support these enhancements when support can be added without
> breaking backwards compatibility. The server should speak 1.1 to
> clients that announce support for it, and 1.0 for clients that do not.
Dan,
I don't speak for Dave Winer but this is my understanding of the
situation: Dave (or his company) owns the trademark XML-RPC. Dave (or his
company) owns the copyright to the XML-RPC spec. Dave will let people use
the XML-RPC trademark if they implement the spec (this is logically a bit
difficult as the spec is unclear in many places and contradicts the XML spec
in at least one place). Dave will let people make changes to and build
extensions on the XML-RPC spec as long as they don't call it XML-RPC.
The reality is that many implementations make quiet extensions to the spec
(for example the Apache XML-RPC implementation handles the Latin-1 character
set, the spec (almost) requires ASCII). As long as they don't make a fuss
about this then Dave leaves them alone. Dave gets unhappy if people do high
profile things like implement <null/>.
Dave, like all of us, is not 100% consistent in the judgements he expresses.
However he has been remarkably consistent in maintaining the above position
for a couple of years now.
The Apache project has a high profile and a well deserved reputation for
respecting intellectual property. It appears to me that you should consider
carefully before adding extension to your XML-RPC implementation.
I do sympathise most deeply with your frustration, however;)
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: frozen specification
Posted by josh lucas <jo...@stonecottage.com>.
Daniel Rall wrote:
>
> josh lucas <jo...@stonecottage.com> writes:
>
> > Daniel Rall wrote:
> > >
> >> "Rick Johnston" <RR...@symantec.com> writes:
> >>
> >> > I guess this is one of the problems of working with a frozen
> >> > standard. The rest of the world doesn't necessarily care whether
> >> > people can use that standard.
> >>
> >> Yeah, I may end up forking away from the standard myself.
>
> > My only word of caution on the possible forking away from the standard
> > is that you have to be careful not to break backwards compatability.
> > Many people are using xml-rpc in a variety of languages and for the
> > 'main' Java implementation to break things would be very bad.
> >
> > Obviously the plan isn't to break things but I just wanted to throw this
> > out there.
>
> Right -- that the XML-RPC specifiction is frozen is a huge mistake.
> AFAIK, an HTTP/1.1 server is fully backwards compatible with HTTP/1.0,
> and offers many enhancments that would be directly applicable to any
> data tunnelled through it (such as XML-RPC). It makes zero sense to
> not support these enhancements when support can be added without
> breaking backwards compatibility. The server should speak 1.1 to
> clients that announce support for it, and 1.0 for clients that do not.
>
yup. I'm totally +1 on backwards-compatible enhancements.
josh
Re: frozen specification
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jon Scott Stevens <jo...@latchkey.com> writes:
> Has anyone tried to email Dave wHiner about this?
I have not -- I've only heard from the people on this list and briefly
browsed his comments in the archives (which support what we've heard
here to date).
Re: frozen specification
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jon Scott Stevens <jo...@latchkey.com> writes:
> Has anyone tried to email Dave wHiner about this?
I have not -- I've only heard from the people on this list and briefly
browsed his comments in the archives (which support what we've heard
here to date).
Re: frozen specification
Posted by Jon Scott Stevens <jo...@latchkey.com>.
Has anyone tried to email Dave wHiner about this?
-jon
Re: frozen specification
Posted by Jon Scott Stevens <jo...@latchkey.com>.
Has anyone tried to email Dave wHiner about this?
-jon