----- Original Message ----- From: "Kimbro Staken" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 11, 2002 5:05 PM Subject: Re: XML-RPC and moving on...
> > 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. +1 SOAP certainly seems too bloated to be used internally. > 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. Separate endpoints is definitely the way to go. Kurt > 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) _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
