On Monday, March 11, 2002, at 06:02 AM, James Bates wrote:
I'll try out this setEncoding() method in XML-RPC. If it works, that would be great.
That would allow us at least to garantee remote Java support. Remote clients should still be disuaded then from connecting through XML-RPC, as no garantee can be made that that remote client will understand the UTTF-8, as the spec doesn't allow for it.
We can't assume UTF-8 at all anyway because many languages simply don't support it. We have no control over that, so I don't consider it a major stumbling block.
We really have two separate issues here. 1. What API do we use internal to the system? 2. What API do we make available to other languages?
For 1. I'm currently -0 on using SOAP. I don't think we need it, we'll be able to make XML-RPC work just fine even if we need to base64 the strings.
For 2. Whether it is XML-RPC or SOAP really doesn't matter that much. In fact, in my opinion, we should expose both at some point. Let's not get too caught up in worrying about this right now. Let's get the core system off of CORBA and just expose a very simple network API to start. If it can'
t be fully UTF-8 in every language, so be it, we can't control that anyway.
Right now I'm +1 for focusing on XML-RPC here too. I'd like to keep things as simple as possible, SOAP can come later and can be focused as a purely external API.
On the other hand, I've also started using SOAP here for something else, and it seems pretty cool... I use Apache AXIS to do all the work and although it's still in alpha developmenmt stage, it seems to work really well (haven't really encountered any issues yet, even using Micro$oft VB clients...)
I think in any case, you first need a Java server-side API that is "RPC-able", as neither SOAP or XML-RPC really have support for "remote objects", the way CORBA or RMI do. The current server API still would require remote objects. Once this API has been made (i.e. only serializable objects are used as parameters and return values in methods)
, making SOAP or XML-RPC of it should be a matter of applying the tools provided with either the XML-RPC or SOAP toolkit...
This is right, we just need a very simple API, let's just forget about any kind of distributed object design. The current CORBA API is an overly complex design.
What I'd like to see is an API that basically exposes two sets of functionality. One highly simple for general clients and one slightly more complex for use internal in the system. The simple API would be built on top of the more complex API. I really hate the idea of adding this complexity, but we really need it to enable more efficient use on the client using the XML:DB API. For instance we should really be parsing documents for insertion as part of the client API rather then handing it to the server. There are several reasons for this, off loading the server,
DTD resolution and enabling more features of the parser i.e schema support. All of this is MUCH easier if done on the client. In communications with the server we just pass around the compressed byte array and symbols used internally by the server.
There are several ways we can expose this.
1. Separate endpoints 2. Overridden methods 3. Extra parameters on methods.
I believe 1. is probably the most robust and least polluted method. For instance with 2. it could be difficult to distinguish some methods and 3. clutters the entire interface.
So for instance we could have
getDocument(String collection, String id)
That returns a string in the simple interface and returns a struct containing the necessary pieces of the compressed document in the complex interface.
Is someone planning to propose an API design?
James
-----Original Message----- From: Kurt Ward [mailto:[EMAIL PROTECTED] Sent: 10 March 2002 01:00 To: [EMAIL PROTECTED] Subject: XML-RPC and moving on...
XML-RPC:
I don't really remember where we left off on the discussion about using XML-RPC on the internals and on the external interface, but I've been doing some work with Apache XML-RPC and found that it does in fact allow for UTF-8 encoding by calling
XmlRpc.setEncoding("UTF8");
I haven't dug into enough XML-RPC client implementations to see how many also support UTF-8, but I'm assuming that probably most do (?).
Moving on:
Where/how/who do we go from here? I'm still a little gun-shy to tear into the internals right now until I have some more time to become more familiar with the existing code. I guess what I'd like to see is the list that Kimbro came up with a while back with some priorities, etc..
Kurt
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
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)
