Comments at bottom > -----Original Message----- > From: Kimbro Staken [mailto:[EMAIL PROTECTED] > Sent: 26 March 2002 16:18 > To: [EMAIL PROTECTED] > Subject: Re: open issues > > > Ahh, OK. Let me explain further, there is a point and I still > believe it's > a worthy one. I was hoping the experimental implementation > would be enough > to make it clear where the potential lies. This is one of > those times I > wish we could just get together in front of a whiteboard and > hash it out. > > The problem is simply that adding parameters to existing method calls > changes the signature of those method calls. This > automatically breaks all > existing clients even in cases where those clients may not > need to have > been broken. Basically my goal is for the API to be easy to > change. We > need this because there is so much about what we're doing > that is still > really fuzzy. > > ...
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...) 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? For the more public API's I would completely understand and endorse the proposed approach; also the advantages provided by parameter ORDER irrelevance Food for thought still I think... James
