Sorry -left out the copyrigth from my previous post:
The snippet from the spec is copyrighted as follows:
"Copyright 1998-2002 UserLand Software, Inc..
XML-RPC is a trademark of UserLand Software, Inc."
-----Original Message-----
From: EXT-Raiteri, Ashley L
Sent: Tuesday, February 26, 2002 12:37 PM
To: '[EMAIL PROTECTED]'
Subject: RE: frozen specification
I'm sure there will be more comments on this discussion, but I 'm with you
on this Dan, as well, as I agree with John.
It would not be wise to "extend" xml-rpc.
I do beleive however that if there is support for it you can extend your
implementation to do whatever you want by providing additional packages that
can be plugged in, in this way you would maintain the spec-compliant core
and also allow for the enhanced functionallity that everyone is clamoring
for.
(For example, the spec doesn't mention error handling. ):
from the spec:
"Response format
Unless there's a lower-level error, always return 200 OK.
The Content-Type is text/xml. Content-Length must be present and
correct.
The body of the response is a single XML structure, a <methodResponse>,
which can contain a single <params> which contains a single <param>
which contains a single <value>.
The <methodResponse> could also contain a <fault> which contains a
<value>
which is a <struct> containing two elements, one named <faultCode>, an
<int>
and one named <faultString>, a <string>.
A <methodResponse> can not contain both a <fault> and a <params>."
There is nothing here that says you can't put it aliasing mechanisms to
catch errors and make things work.
For example, if the return value is null, the implementation could easily
recast this to be:
HTTP/1.1 200 OK
Connection: close
Content-Length: two cents
Content-Type: text/xml
Date: ***, dd mon year dd:dd:dd GMT
Server: UserLand Frontier/5.1.2-WinNT
<?xml version="1.0"?>
<methodResponse>
<params>
<param>
<value/>
</param>
</params>
</methodResponse>
I am NOT saying this should be done, just that it COULD be done, the same
goes for add support for HTTP 1.1
I'm not so sure about unicode, but on a case by case basis,
extension.modification can be done in a "wrap" way that
keeps the integrity of the core (and therfore the spec) in place.
two cents
ashley
-----Original Message-----
From: Daniel Rall [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 26, 2002 11:54 AM
To: [EMAIL PROTECTED]
Subject: Re: frozen specification
"John Wilson" <[EMAIL PROTECTED]> writes:
> ----- Original Message -----
> From: "Daniel Rall" <[EMAIL PROTECTED]>
>
>> 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
