OK clouds are beginning to lift: as far as I can make out here, the issue then is "method overloading" (as I'm used to calling it in Java). Now is
this not possible using the XML-RPC toolkit? (As you seem to suggest: and I admit I had more or less taken this for granted without checking...)
Sorry, I didn't mean to suggest that. Yes you can override methods but it'
s cumbersome to do things that way. Especially when you rely heavily on string parameters.
In case it isn't, would some other toolkit not allow it, like the one Paul Hammant just suggested?
On the other hand, we're discussing the INTERNAL API here, to make Xindice accessible in client/server. The ONLY client using this API will be THE xindice XML:DB driver (which will/should be part of the core distribution, as is the case of the CORBA affair now), surely? Is worrying about breaking "clients" really an issue at this level?
Ahh, now I see what we're missing. I'm proposing this API as the only XML-RPC API not just the internal API. With the high parameter flexibility there's absolutely no reason for separate endpoints for compressed and non-compressed communications. This was one of the big appeals of this to me.
For the more public API's I would completely understand and endorse the proposed approach; also the advantages provided by parameter ORDER irrelevance
Ok, good. That's what I've been proposing all along. :-)
Food for thought still I think... James
Kimbro Staken Java and XML Software, Consulting and Writing http://www.xmldatabases.org/ Apache Xindice native XML database http://xml.apache.org/xindice XML:DB Initiative http://www.xmldb.org
