Tomorrow I would like to move the DTM_EXP branch to the main branch.  The
branch is not absolutely perfect, but it's pretty damn good, and I think
any final polishing should be done on the main branch.  I would also like
to get any ongoing bug fixes into the DTM version instead of the existing
trunk.

I expect that the first couple of days people might encounter some issues
with extensions (a fair amount of *internal* api has changed), but I don't
think we can discover these and resolve them one way or the other until we
get it in the mainstream.

I will branch the existing trunk, so that people can still work off that if
they absolutely have to.

I won't immediately merge any of the bug fixes from the last two weeks
(since we last did a merge to DTM_EXP).  Instead over the next couple of
days we will merge any bugfixes in, or the bugfix authors can do it.

The SQL extension will be broken to start out with.  John Gentilin is
working on this (I hope), and it should be functional within a week or two.

In general the DTM work (not just the DTM, but all the work on the branch)
provides faster performance and lower object garbage... though it is an
ongoing battle.  Brief summary of the work:
1) The DTM itself, which presents node identity as 32-bit integer handles.
The DTM has many features, including direct character dispatch to SAX2,
native DTM iterators and "traversers", multiple document management, etc.
2) Joe Kesselman's CoRoutine parsers, which are in a threaded SAX flavor
and in a Xerces parseMore() flavor (no threads).  These do away with the
"race" conditions that occured in the original code, and should make Xalan
much more robust.
3) *Much* more robust XPath itteration.  The "waiting" iterators of old are
no more, and good riddance.  There is stil lots more we want to do with
this mechanism.  (There is something here called MatchIterators, but it's
not being used yet for various reasons.  We will be taking advantage of
these down the line.)
4) A fair amount of XObject creation reduction.  You can now get boolean,
number, nodeset, and string values directly from an Expression, instead of
going through an XObject.
5) XMLString, which makes it so we can have string objects that don't wrap
Java's String object, but instead get their character data from an array or
Fast String Buffer.
6) Serializers now only do internal buffering if they know they are writing
to a FileStream.
7) The variable stack mechanism has been redisigned, so that it is no
longer so interpretive, and is much more robust, I think.
8) Some small amount of stylesheet rewriting (but not yet redundent
expression elimination), in particular to reduce full RTF creation and
interpretation.

Please let the list know if you have objections to moving this branch to
the trunk tomorrow.

-scott



Reply via email to