I'd like to propose an API with one method in it.
Hashtable run(Hashtable message);
It's still an RPC like API but based on a more flexible message mechanism rather then static parameters.
Instead of defining methods with static sets of parameters we would define messages that have any number of parameters and that can change over time.
For instance instead of calling the insertDocument method via XML-RPC like this.
Vector params = new Vector();
params.addElement("/db/root");
params.addElement("test");
params.addElement("<doc>value</doc>");String result = (String) client.execute("insertDocument", params);It would be called like this.
Hashtable message = new Hashtable();
message.put("method", "insertDocument");
message.put("collection", "/db/root");
message.put("key", "test.xml");
message.put("document", "<doc>value</doc>");Vector params = new Vector(); params.addElement(message);
Hashtable result = (Hashtable) client.execute("run", params);
String key = result.get("result");In Java the code is longer but will be simpler in a scripting language which is where I expect most direct use of the RPC API to exist. Java developers should still use the XML:DB API.
For instance in Perl to setup the message would just be.
%message = (
"method" => "insertDocument",
"collection" => "/db/root",
"key" => "test.xml",
"document" => "<doc>value</doc>"
);$result = $client->execute("run", ($message));My Perl is rusty so this might not be exactly right, but close enough.
This has several major benefits
- Named parameters make the code more self documenting.
- The order of parameters does not need to be known.
- The API is completely dynamic and extensible. You can both add messages and add parameters to messages easily.
- There is no need for separate endpoints for internal and external apis. You simply set different parameters to pass compressed docs vs. uncompressed docs.
- The API could be user extensible by simply defining a package or filesystem location and then dynamically loading classes from there that match the name of the method.
The server side implementation of this will be a little more complex because you have to build the dispatcher, but it is straight forward code.
This also gives us a clean way to invoke XMLObjects remotely.
I realize that for Java developers this can be considered "kludgy" or "ugly" or "sloppy", but the calls can be wrapped in what ever client API you want. That client API will still be brittle, but I'm not worried about that. XML is supposed to be about flexibility and lately I've really been bothered by how inflexible Xindice has become. I also realize that we don'
t need XML-RPC or SOAP to implement something like this, but I still think the client libraries are valuable.
What are the reasons not to do this?
Kimbro Staken - http://www.kstaken.org - http://www.xmldatabases.org Apache Xindice native XML database http://xml.apache.org/xindice XML:DB Initiative http://www.xmldb.org Senior Technologist (Your company name here)
