Xindice architecture re:dbXML [WAS: New committers]

[Murray Altheim <m....@open.ac.uk>]

[pls. note change of subject line to match thread...]

Tom Bradford wrote:
[...]

> There are several things that I've done to the low-level dbXML engine 
> that can benefit Xindice.  For example, I've implemented the DTSM spec 
> that I proposed quite a while ago (which people kindly ignored).  It 
> completely removes the dependency on a proprietary DOM, improves 
> read/write performance by eliminating recursive treewalking, and makes 
> converting between various XML APIs much easier.  It does introduce some 
> major changes to the internal APIs though, as you no longer read/write 
> DOM Documents.  This dependency wouldn't be exposed via the XML:DB APIs 
> though.


Perhaps I'm reading this incorrectly, but I'm a bit confused. If the
APIs you've published [1] are accurate to your current model, you still
do seem to expose the possibility of reading and writing via DOM Documents,
such as ContentClient.setDocument() and ContentClient.getDocument(). Since
that's essentially the functionality I need for XNode, I'm happy. I
haven't really used XML:DB much at all, though I think it should be
supported.

If what you're saying is only that the dependency on a proprietary DOM
is removed (and I'm simply reading your wrong), I would certainly welcome
that.


> Another thing I've done is removed the multi-rooted aspects of the BTree 
> system.  Before, unique values would resolve to a pointer to a separate 
> btree root that maintained an ordered list of entries (keys, locations) 
> that matched that value.  This indirection not only slowed things down, 
> but bloated the index files for values that weren't repeated.  The dbXML 
> btrees have multi-part keys, eliminated the indirection and the bloat.


Are there any unresolved i18n issues here?

 
> Also, dbXML abandons the XML:DB API as its primary API.  It still has an 
> XML:DB driver, but I've developed a set of interfaces that more closely 
> resemble the dbXML internal APIs (and to a degree, the Xindice internal 
> APIs).
> 
> Anyhow those are some of the things that can be introduced into the 
> Xindice code.


Well, I'm as sensitive as anyone about stepping on toes, but if
Kimbro (who would likely the only one with toe issues) has no
problem with you becoming again a fundamental architect in Xindice,
I'm with those others that would certainly welcome you back, with
the trust in your abilities to keep the design true.

Murray

[1]
 > FYI, The dbXML JavaDoc is available at:
 > http://www.dbxml.com/api/index.html  The related packages are in
 > com.dbxml.db.client, com.dbxml.xml, and com.dbxml.db.core
......................................................................
Murray Altheim                  <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK

            If you're the first person in a new territory,
            you're likely to get shot at.
                                                     -- ma

Re: Xindice architecture re:dbXML [WAS: New committers]

[Tom Bradford <br...@dbxmlgroup.com>]

On Monday, October 21, 2002, at 06:38 AM, Murray Altheim wrote:
> Perhaps I'm reading this incorrectly, but I'm a bit confused. If the
> APIs you've published [1] are accurate to your current model, you still
> do seem to expose the possibility of reading and writing via DOM 
> Documents,
> such as ContentClient.setDocument() and ContentClient.getDocument(). 
> Since
> that's essentially the functionality I need for XNode, I'm happy. I
> haven't really used XML:DB much at all, though I think it should be
> supported.

The client APIs do provide DOM/text/binary reading and writing, and 
could probably easily be extended to support SAX.  The internal APIs 
are what all based on the DTSM APIs and binary.  And yes, the 
dependency on a proprietary DOM is also removed.

--
Tom Bradford - http://www.tbradford.org/
CTO - The dbXML Group - http://www.dbxml.com/
Apache Xindice - http://xml.apache.org/xindice