I think the current names are fine actually... the server contains only server code, core contains the database whether used by a server, or directly by the embed driver, and client contains code to -generically access the server, and package this server access through XML:DB or possibly other means (tb determined later)...
As for the embed driver, it allows embedded access to Xindice, it seems right to me also. I would however wish to look at optimizing some of the internal workings. For example: 1) there's a complete B-Tree implementation, and XML documents are in fact trees, but are stored simply as byte arrays... Why not store NODES in the B-Tree, allowing much more clever indexing 2) Xindice internally handles all XUpdates, Queries, everything by completely loading an XML document into an in-core DOM object model. Storing nodes in stead of documents would also allow this to be far more optimized. In particular, XUpdate's could TRULY update the db, in stead of reading a DOM, modifying and writing a complete document back. 3) Introduce some transaction and failover support; don't know where yet: the pages of the Paged file? complete B-Tree's ? documents in collections? > -----Original Message----- > From: Vladimir R. Bossicard [mailto:[EMAIL PROTECTED] > Sent: 05 December 2002 09:57 > To: Xindice Dev > Subject: [2.0] Shaking up the tree > > > Hi all, > > I suddenly can't send email from my other webmail > account, so I will temporarly use my yahoo address. > But use "[EMAIL PROTECTED]" or > "[EMAIL PROTECTED]" to sent me private emails. > Thanks. > > Anyway, I've been thinking of 2.0 these days and since > we can affort to break users' code (I assume), let's > shake the tree. :-) > > Xindice is not a server anymore but this aspect is > still present in the packages: xindice.client and > xindice.server. Xindice is providing an XML database > and accessors (implementing the xmldb framework) to > handle the database. So why not having the following > organization: > > - xindice > - admin (Kurt's admin tool) > - core > - accessor > - xmlrpc > - message > - embed (*) > - ... (like SOAP, WebDAV...) > - util > > (*) I do not particularly like the name "embed" > because it denotes a usage and not a technology but I > couldn't find a really better name. > > How the different accessors are defined is not > Xindice's problem. Some implement a client/server > solution (xmlrpc) other not (embed). > > Thoughts? > > -Vladimir > > > ===== > Vladimir R. Bossicard > Apache Xindice - http://xml.apache.org/xindice > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com >
