Gianugo Rabellino wrote:
> Mark J. Stang wrote: > > 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. Actually, they both Publish and Subscribe. The Server subscribes to requests for data. The Clients Subscribe to changes to their data. They communicate via Publish/Subscribe. > > > 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. > I think the bottom-line is that the embedded version of Xindice is available to build stand-alone applications or other servers. As such, it is valuable to many members of the Xindice community. I am very disturbed that you see a future where it doesn't exist. Like it is a bug you plan to remove in the future. IF THAT IS THE CASE SPEAK UP NOW AND I WILL FIND ANOTHER DB. SO PLAN ON LIVING WITH IT FOR 1.X, 2.X, ETC. And no, my caps lock key is not stuck in upper case. > > > 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 Ciao, Mark -- Mark J Stang System 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
