Actually, these kinds of semi-structured messages rather than rigurous
method
signatures, is one of the ways you can use SOAP, if I�read it right. In
stead of WRITING code
to handle it on the server, we'd want to use existing SOAP code if we
went that way, I think.
�
James
-----Original Message-----
From: Kimbro Staken [mailto:[EMAIL PROTECTED]
Sent: Sat 3/16/2002 10:40 AM
To: [EMAIL PROTECTED]
Cc:
Subject: [proposal] API a different approach
Tonight I was thinking about the API a bit and it's been kind of
bothering
me that maybe it isn't the right way to go. My concern is primarily that
the API will be brittle and not extensible. This was a major problem with
the CORBA API and I hated it. Now that we have the opportunity to fix it,
I think we should consider a different approach.
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?
