I would tend to agree with Murray on this, but would also like to
mention that maybe Xindice's home is no longer in the XML project, and
that the project may benefit from significant overlap that will
ultimately come from the Apache DB project. The building blocks of
Xindice are just basic database algorithms and such, it's only when you
start to layer the veneer of XML that it becomes an XML database. I
would also say that if there's any full text indexing to be borrowed,
it should probably come from the Lucene project, just to keep
everything in the family.
--
Tom Bradford - http://www.tbradford.org/
CTO - The dbXML Group - http://www.dbxml.com/
Project Labrador - http://www.dbxml.com/labrador/
On Dec 5, 2003, at 10:29 AM, Murray Altheim wrote:
Kevin Ross wrote:
I have spoken with Wolfgang quite a while ago about this, and he
expressed potential interest in becoming a lead for the project.
Issues:
-potential mismatch in goals
-upfront effort involved in merging.
I was left with the impression that, if dedicated help was provided on
the part of xindice, the projects could be merged together.
All active exist committers would of course need to be inducted into
the
new project.
As you may be able to tell, I would be *very* interested in seeing
this
become a reality.
Merging two different code bases written by different programmers
with different styles, using different approaches to the same
problem would probably be as much work as starting from scratch. Some
of the basic ideas in each could be modified and used, such as grabbing
eXist's text searching features, but the number of bugs introduced
in a merge of this sort are probably more than a redesign. What is
probably needed here would be an evaluation/comparison of the core
of each database, a design architecture written up from the decisions
made in that comparison, then either a modification of the best of
the two cores, or a rewrite based on the new architecture. Then, each
of the design features considered a requirement for delivery would be
pulled from each of the projects and either rewritten or written from
scratch according to the new architecture.
With the amount of effort necessary to do something like that, with
the commitment required of the team of programmers, I would think
that effort would be better spent simply cleaning up one or the
other of the existing codebases and getting something out the door.
It would probably be at least a year before there'd be something
stable coming out of any merge project. I could be wrong, certainly,
but I'd be very surprised to see a merged eXist/Xindice in stable
1.0 by next December, whereas having either at a stable and
functional point by next March would not be inconceivable. I've
managed a few projects in my day and this one wouldn't be trivial,
especially with distributed talent.
Just to be clear about what may be misconstrued by things I've said,
I'm not in favour of retiring Xindice, but I think that merging
eXist and Xindice might possibly kill both of them. I try to take
what I consider a realistic, not overly optimistic view of this given
the history. The real issue here is as Tom and Kimbro have stated:
the need for one or more programmers skilled in database internals
and XML. There's a false economy in trying to merge two faltering
projects (not to say that eXist is faltering; I don't know its
status).
Murray
......................................................................
Murray Altheim http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK .
[...] all matters of authority and responsibility are ultimately
matters of social practice, and never matters of ontology (that
is, never just a matter of how things in fact are in the nonhuman
world). [...] just as we should not look to ground our moral
judgments in the nonhuman authority of a god, so we should not
look to ground our empirical judgments in the nonhuman authority
of an external world. -- Robert Brandom
http://www.tilgher.it/brandom.html
