On Sat, 09 Aug 2003 21:00:21 -0700, Kimbro Staken wrote: > I've seen a number of posts referring to the XML-RPC API as being > private. That was certainly never the intention when it was originally > written. The major reason it exists is to give other languages access to > Xindice, which means it needs to be a publicly documented API. Or > lacking documentation, it at least needs to be considered OK to develop > against it if you can figure out how. What's the reason for preferring > otherwise?
My reason is simple. I need to make a number of changes to the payload to fix outstanding bug reports (see http://marc.theaimsgroup.com/?l=xindice-dev&m=106026306508909&w=2 ). If it's private (ie unsupported) I can feel free to fix bugs without the need ensure that the solution is backward compatible. All I need to ensure is our unit tests execute for the xml-rpc driver. If someone wants to go ahead and create a driver for another language, that's fantastic. We should feel free to fix the bugs in our supported drivers as we see fit. Even if this means changing the payloads of the packets and breaking the third party driver. Beyond the fixes I have a number of improvements I want to do to the xml-rpc driver (lazy loading of paged results being one of the bigger ones). These things will certianly break compatibility. I suppose that we could say that we maintain compatibility at the payload level in bug fix releases (eg 1.1.1) and not . releases (eg 1.2). As long as we are happy to leave bugs in the bug fix releases that require a change to the payload. -k.
