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.
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?

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
> 
> 

Reply via email to