Uhm. I'm in the process of anaysing whether we can make DTM strictly an internal representation, replacing Node Handles with flyweight "cursor" objects, which would encapsulate both node access and document traversal. The result ought to be more maintainable, more efficient when wrapped around non-DTM data sources, and probably more efficient even when accessing DTMs since it'd avoid the overhead of translating between Node Handles and Node Indexes.
I'm not immediately sure how that interacts with Morris's proposal. I think it may achieve many of the same results via a significantly different route, fully encapsulating DTM rather than fully exposing it. If we're really going to reconfigure DTM as a back-end representation, there may be questions about whether the resulting API would be one we'd *want* to expose.
The dtm jarfile is an interesting proposal, but we might want to shelve it until we have a more solid proposal for what the cursor-based API would look like and how DTM would be changed to better mesh with it.
______________________________________
Joe Kesselman / IBM Research
- [Proposal] DTM separation work mkwan
- Re: [Proposal] DTM separation work Joseph Kesselman
- Re: [Proposal] DTM separation work mkwan
- Re: [Proposal] DTM separation work Joseph Kesselman
- Re: [Proposal] DTM separation work ilene
- Re: [Proposal] DTM separation work Joseph Kesselman
- Re: [Proposal] DTM separation work mkwan
