Graham Seaman wrote: > On Fri, 21 Jun 2002, Mark J. Stang wrote: > > > All we are going to do is to provide a way to "link" in the > > Xindice code into anyones application without having to have > > any network traffic. It will be an alternate means of access. > > Currently, there are two ways to access data. One is via > > CORBA, the other is through RPC. Using the CORBA method > > you can start Xindice up as a seperate process or as part of your > > own application. However, it still uses CORBA to access the > > data. This means that is has to marshall and unmarshall to the > > server and then the same on the way back. Even if it is running > > inside your JVM. What the "embedded" project is going to do > > is to provide an implementation of the XML:DB API. The API > > will be the same as the CORBA version and I think the RPC > > version. The only difference will be that it will directly access > > the data without any middleware. So, it will just be a different > > import to use the networked vs the non-networked version. > > > > Does anyone disagree or see a problem here? We are just about > > ready to start... > > Not really a problem but a question: I'm in the process of writing a perl > XML:DB front end to Xindice and eXist (also on sourceforge :-). In both > cases I can only access the db over XML-RPC, which as you point out > already involves large amounts of marshalling and unmarshalling (and in my > case even more - to get a ResourceSet from the XML-RPC output I have to > parse the output into a DOM tree to break it up into separate Resources, > and to do XUpdates on a Collection I'm actually having to fetch each > document over XML-RPC, apply the XUpdate, and store it again...). It would > be so much faster if I could just access the db over a socket (or failing > that if the XML-RPC interface, or any other interface, provided more > transparent access to the internal XML:DB API). > > So the questions: > 1. would there be any plans in your project for fast > language-independent access? My ideal would be if I could treat the DB as > a resource without caring what language it was written in, like I can with > relational dbs, but without loosing huge amounts of efficiency in the > process.
Probably the best solution there would be a CORBA client. CORBA gives you independent clients. However, with CORBA being deprecated, that might be a problem... People have suggested that keeping the CORBA implementation might be a good idea. I don't know what the exact plan is at this moment. IMHO... > > 2. Or if the project just allows people to embed Xindice > within a Java application more efficiently, could this be a simple wrapper > application to allow external access to the XML:DB API through a socket? > Is anyone planning to do this? It would be possible, but someone would have to create a messaging mechanism. And if you have to create a messaging mechanism, then you might as well use either RPC or CORBA. What I have been doing is building my own database server, based on Xindice. It uses Java Messaging Service(JMS) and a SQL like query language. I don't know of any non Java JMS clients. However, you could take XMLBlaster, which I think has a Perl client and create your own server like I am. I didn't use XMLBlaster because it didn't support JMS, I don't think it does currently. I am sure Heinrich will correct me if I am wrong. It was my first choice, but by using JMS I can swap out JMS Servers. If you did this then you could define your own requests. You could use XML for the message packaging, but that is pretty similar to what RPC is doing now. You are asking for a particular solution. There are several ones that exist now. What is the problem with those? Is it speed? Is it the amount of code you have to write? Maybe the group can address those? JMHO. > > Hope the questions make sense... I'm a bit new to all this area... > > Thanks > Graham > > > > thanks, > > > > Mark > > > > Kurt Ward wrote: > > > > > I'm going to disappear for a couple of weeks while I move across the > > > country. > > > I am looking forward to continuing the development of the server, but I'm > > > not sure > > > what is/needs/should/could/have-to be worked on at this point. Most of > > > the > > > basic > > > XML-RPC API is in CVS along with the unit tests. Not sure if anyone has > > > looked > > > at it yet, but it seems to be getting there. Some of the changes I have > > > made may require > > > a few modifications to James Bates XML:DB code in the CVS scratchpad > > > (James, > > > if you are still around it would be with GetDocumentCount() and > > > GetCollectionCount() due to XML-RPC types). I'm also a little confused > > > with > > > all of the messages about working on a stand-alone server. Don't get me > > > wrong, I think this a GREAT idea, but to me it leaves the other pieces > > > hanging a bit. Is the server to become stand-alone with separate access > > > layers? Or is that later down the road than a 1.1 release? > > > Kimbro/Tom/James: Let me know what you would like me to spend time on > > > once > > > I get up and running, I'll be itching to get at the keyboard. > > > > > > Kurt > > > > -- > > Mark J Stang > > Software Architect > > Cybershop Systems > > > > regards, -- Mark J Stang Software Architect Cybershop Systems
begin:vcard n:Stang;Mark x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] fn:Mark Stang end:vcard
