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
