copyright

["EXT-Raiteri, Ashley L" <as...@boeing.com>]

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: 'rpc-dev@xml.apache.org'
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:dlr@finemaltcoding.com]
Sent: Tuesday, February 26, 2002 11:54 AM
To: rpc-dev@xml.apache.org
Subject: Re: frozen specification


"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: copyright

[Daniel Rall <dl...@finemaltcoding.com>]

Can you teach your email client how to set the References header?  The
stray posts are kinda annoying...

Re: copyright

[Daniel Rall <dl...@finemaltcoding.com>]

Can you teach your email client how to set the References header?  The
stray posts are kinda annoying...