James, Folks,
In case you did not know there is a Java only RPC tool called AltRMI. It is going to be faster than going to XML etc, and if you had a need to use it for this project I'd be more than happy to help. It, of course, breaks one of your design goals (to use XML for interoperability), but if your need is /entirely/ internal to Xindice even in a federation of Xindice servers, I don't see a problem. Horses for courses - it is fast and has multiple transports, has a decent interface/impl separation.
See http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/altrmi/ Some of the classes in the test package should be self explanatory.
It is in use in Avalon (generic "transport" package in avalon-cornerstone and client for new "instrument" package in avalon-excalibur). Two of the demos in avalon-apps use the transport package. An entire off Apache project called Enterprise Object Broker (EOB) is using it and a few private companies are using it for unknown tasks.
It has its uses and limitations, but you'd be fooish to dismiss it after a one minute analysis.
- Paul
OK guys; sorry for having not responded earlier... I've been kind of busy (at the OpenCMS conference in Z�rich; Xindice was mentioned 3 times! Yippie...) and will be busy for a few more days on some non-Xindice stuff... However after that, I fully intend once again to participate actively in the project.
Some points I'd like to mention:
- about the internal RPC API:
====================
Kimbro you proposed a solution passing big hashtables back and forth accross the RPC tool. I'm sorry, but I don't see the point? At the bear-bones level, you'll always need server code that implements the various methods/functions/operations/whatever-you-call-them with the appropriate arguments that you need. If you want to add a new method/function/whatever, you'll still have to add server code...
Equally the client needs to know the available methods and still needs to prepare parameters and send them, using some means for each function/operation/method it needs.
Now in a pure RPC approach, client and server would do their stuff (implementing functions (server) and calling functions (client) using constructus familiar to that language itself (Java, C, perl, whatever) and the RPC tool should take care of seeing everything gets sent accross the network as it should. Also we agreed that XML-RPC does this well, even intl chars, in the special case of Java clients and servers (which is what we do in the internal API).
If you make big hashtables and write only one Java method on the server that checks the hashtable and looks up a method, casts the hashtable's contents and sends them to the appropriate method, aren't you actually duplicating the server-side skeleton functionality? something that the RPC toolkit already could do (and does) really well? I don't see the gain, because you still need to write all server functionality, and you need to support an additional server marshalling/unmarshalling/dispatching function...
I'm fine by XML-RPC or whatever RPC tool, but I think we should really USE it.
- Using SOAP:
==========
As long as all unicode characters can be handled when passing java.lang.String's accross XML-RPC from JAVA code to JAVA code, I'm fine with any RPC tool, and I agree XML-RPC is simpler, so would prefer it. (I simply didn't know about the setEncoding() before). I also fully understand that non-unicode languages can't be expected to handle these incoming strings naturally in their own string equivalent, and even with SOAP this wouldn't improve anyway. Besides we don't need other languages in developing the internal API.
Any external API could provide alternatives sending byte-streams or base64 strings or whatever.
In light of all this, I support the view of most people here I think, which is to have a SOAP interface as a "high-level" API, alongside possible a high-level XML-RPC, a WebDAV interface, and possibly others
all built on the internal API...
- Patching code to use UTF-8 as internal string representation:
============================================
Indeed I will start patching the code to do this, in a few days. I repeat that the major outstanding issue here, is that Strings passed accross the CORBA API weren't handled well, causing problems for all queries, amongst other things. Together with the switch to RPC, this should be resolved automatically.
But I repeat my commitment to fix this probably by next week.
Also if my reasoing in the first points convinces anyone, I'd like to write a XML:DB connector that behaves as a client to the original well-defined RPC JAVA API I had made, to complete the cycle and get something fully operational.
James
