I assume this is what you mean by Fulcrum
http://jakarta.apache.org/turbine/fulcrum/index.html. All I can see
that buying us is a dependancy on Turbine which is the last thing we
need. The lack of documentation for XML-RPC is on the messages that we
use, not on how to configure the XML-RPC stack. Fulcrum won't help with
that. Documentation would take a couple hours to write, but there's no
point if the API is going to be considered private.
On Thursday, August 14, 2003, at 08:48 AM, JC Tchitchiama wrote:
Greetings all,
I have always wondered why fulcrum was not used/considered to be the
XML-RPC
for Xindice. Can anybody give us some backgrond on that please ?
The reason I think my question is related to Kimbro's question is that
Fulcum
is documented ?
On Sunday 10 Aug 2003 11:14 pm, Kevin O'Neill wrote:
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.
--
Best Regards.
JC.
\\- - -//
( @ @ )
===oOOo-(_)-oOOo=================================================
[EMAIL PROTECTED]
=================================================================
Kimbro Staken
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
