Hi all,
Well after listening to all this discussion I just had to
pitch in. I have been using XML-RPC for a long time and worked with
implementations in perl, java(helma/apache) and c++ (Eric Kid). I
must say that it is simple and very interoperable. This is due to,
at least in part, having a frozen spec.
We must respect the holder of the spec, even if we don't totally
agree with him. I would love to see XML-RPC transform into a real
standard, but until that happens we must make the best of what we
have.
We as users/developers should fight to keep the spec from
fragmenting. I really agree with John on this. If changes were
allowed to happen unchecked, then every language/implementation would
want their own feature, such as the null for us java folks.
Maybe someone could come up with a proposal to form a formal standard
around the XML-RPC spec. There are getting to be many XML-RPC like
protocols in the wild and I would love to see XML-RPC survive in this
space. Unfortunately a static spec has little chance competing with
SOAP, Suns JAX_RPC or any of the others.
As for the NULL thing:
Changing over to the apache code base was a pain because of the
"missing" null support. But I was able to do it without too much of
a problem. My code is now much cleaner for it. So ok, taking the
time to do rewrite helped also!
Just my 2 cents.
Thanks for listening.
Rick
>I've never used a version of the server which supports null and don't
>intend to spend any of my time on it. So it's not a problem for me
>and never will be.
>
>Chad Ward <[EMAIL PROTECTED]> writes:
>
>> It actually is a problem, because there is code that exists that is
>> expecting "null" to be valid.
>>
>> Chad
>>
>> -----Original Message-----
>> From: Daniel Rall [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, February 26, 2002 4:11 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: frozen specification
>>
>>
>> Chad Ward <[EMAIL PROTECTED]> writes:
>>
>>> Would it be possible that the current implementation be backwards
>>> compatible? Anyone who was using the helma implementation that had null
>>> support probably has no use for the current implementation, because it
>>> doesn't have null support.
>>
>> Any future changes will remain backwards compatible within major
>> releases (i.e. 1.0 will be compatible with 1.1). Only in major point
> > releases would incompatible changes be considered. I wouldn't worry.
--
