There are several people who are using the embedded driver on this list. I wrote an XML Server. I can send it requests like "select customer from customers where lastname = 'Stang'". It is a stand-alone process. It communicates via JMS. So, my Clients "publish" requests for data and my server "subscribes" to those types of requests. When a request comes in, it processes it and "publishes" the response back to the clients.
I have never heard of such a kind of inversion of control... client publishing and server subscribing: quite funny, but if it works for you, it's OK.
I decided to have a single process non-server version of my application. By using the embedded version in my client, I can remove all the other server processes. This is great for demo programs and for Customers who might want to try before they buy. I can send them the embedded version/single user and they can key in real data and see the application in action. If they decide to buy, I ship them the server jars, start the server processes using the data from the embedded version and they don't loose anything.
With the single user version, I can "upgrade" my customers to a multi-user version without having to re-install the entire application. I change one jar on the client, install the server, move the db directory and I am done.
OK, until now you are making a technical point from a convenience functionality. Which is fair, but IMHO doesn't really pay off from what we are losing from an architectural and developer POV: we have to maintain two drivers, keeping them in sync and evolving them at the same pace, which requires a lot of effort. Way too much, for having just the commercial convenience of being able to switch drivers and version between a demo and an uncrippled version (true, this convenience would apply to other scenarios as well). But the embed driver is here and this is not really a choice anymore, at least for 1.x, so enough ranting.
My only concern is that Xindice gets an extra layer on top of what is already there that I won't have any use for. I would like to see the embedded driver be able to bypass the security. I think it should either be an API on top of the embedded driver.
There are no API to invent, actually. We already have the only API we need (well, not really, let's say it's the only one we can use) at the XML:DB level, which is Database.getCollection(collection, user, password). Other than that, I'm not that much willing to go with the official distribution: of course there will be some possibility to hack your way through the AAA code (which, if will be JAAS based, will be for sure flexible enough), but I don't see this as an option for the mainstream development.
Ciao,
-- Gianugo Rabellino
