SOAP has its uses, but I just don't see it being what we need. I have no problem with a public SOAP API, though I still feel it should be secondary to XML-RPC and should not be used internally in the system.
On Saturday, March 16, 2002, at 03:12 AM, James Bates wrote:
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?
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)
