Mailing-List: contact general-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xml.apache.org
Date: Fri, 19 Oct 2001 01:29:24 -0700
Subject: Re: AW: [vote] A native XML database project under Apache
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v472)
From: Kimbro Staken <kstaken@dbxmlgroup.com>
To: general@xml.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <71674BEFF0E2D41196F500600811AA6B101FEE@TUP-BO1-EXC>
Message-Id: <6704456A-C46B-11D5-8CA5-00306571C01C@dbxmlgroup.com>


On Thursday, October 18, 2001, at 11:56 PM, Henning von Bargen wrote:

> +1 from me (but I'm not a committer).
> It is something we all need.
>
> But besides discussing a name for it,
> it should be clarified what the project goals are.
>
> For example:
>
> Do we want a 100% pure Java solution?
>  I like Java, but I like the Apache HTTP Server as well.
>  Maybe some low-level routines (caching, I/O, Parsing) could be
>  implemented in C using the existing Apache framework including SSL
>  for the sake of performance.

We actually did this in the very early days of dbXML and it was far more 
trouble then it was worth. It might be a good idea in the distant future 
when you reach the point of needing that last bit of performance. By then 
though, I still doubt it will be worth the trouble.

>  Using the existing Apache C framework could have some benefits.
>  Roughly spoken, a database server is not too different from a web server:
>  It receives requests from many clients and services them.
>  The communication between clients and server needs to be secure.
>  The main difference is:
>  A web server usually returns a file from the file system to answer a
> request,
>  whereas a database server reads and manipulates the database storage
> system.
>
> Do we want the database to have all the features that
> full blown-up database servers like (just for example) Oracle 9i have:
> - transactions
> - automatic recovery after crashes

Absolutely. Solidifying this area is the highest priority we have.

> - clustering with cache sharing

Probably in the future but I doubt this should be tackled in a first 
effort.

> or do we just want (to keep it simple)
> only a single-process database running on a single server
> with no transactions and no recovery options?
>
> I am am not an expert, but the part that seems to
> be most interesting (and difficult) for XML databases
> is effective storage and indexing.
> I expect several new ideas to come up in that topic in the next few years.
> Thus, the database should be quite flexible in the implementation
> of storage and indexing.

Yes it should and dbXML is already pretty flexible in this regard with a 
virtualized filing and indexing system.

http://www.dbxml.org/api/org/dbxml/core/filer/Filer.html
http://www.dbxml.org/api/org/dbxml/core/indexer/Indexer.html

Kimbro Staken
The dbXML Project
http://www.dbxml.org


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org