I wouldn't say that removing null support has made XML-RPC "useless" for people who previously relied on it. I'm sure it is causing some headaches. It would be interesting to hear how people work around this.
I know I'm to blame for implementing this feature when it was only a proposal, and removing it when it was turned down (not just by Dave Winer, but also by other members of the XML-RPC community like Eric Kidd). Sorry about that. But I think it was the right decision to stick to the spec after all. Hannes Chad Ward wrote: >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. > >Just my 2 cents. > >Chad > >-----Original Message----- >From: josh lucas [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, February 26, 2002 9:25 AM >To: [EMAIL PROTECTED] >Subject: Re: frozen specification > > >Daniel Rall wrote: > >>josh lucas <[EMAIL PROTECTED]> writes: >> >>>Daniel Rall wrote: >>> >>>>"Rick Johnston" <[EMAIL PROTECTED]> 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 >
