Alternative to the Live NodeIterator

It seems like the concept of a 'live' NodeIterator is a very heavy demand to
place upon DOM implementors.  In fact, I don't think a single DOM
implementation deals with this yet.  I'm assuming the reason for this type of
demand is to make up for the fact that authors cannot override the DOM Nodes.

What is the need for this prerequisite, especially since the DOM assumes all
DOM methods occur in the same thread?  It seems to require that a globale list
of all NodeIterators be maintained somewhere, each with a abstract description
of the search criteria.  Every time a node is added (or worse, an entire
tree), it has to compared every search criteria and additional processing may
be require to determine ordering.

The only reason I can think of for this, is to allow authors to keep track of
which nodes they have or have not processed with a before/after
currentPosition analogy.  I think this could be replaced by a form of property
set associated with each node, similar to the Client Properties of Sun's Swing
classes for Java.  In this system, a hashtable is connected to every node
(Jcomponent in this case), and anyone is allowed to put/get Object based
key/value pairs.  This allows a lot flexibility by allowing any type of data,
and therefore any amount of data as well.

In the rare possibly a user would want to repeatively process a set of Nodes,
the user would acquire a new NodeIterator with each new cycle.  Then the user
would query each node for his key. If the key was not found, they the node has
never been processed.  This would allow user action upon finding the new node.
The draw backs would be the repeated search times in creating the new
NodeIterators.

This system could easily be implemented by single back-end Hashtable, where
the node and user key pairs act as teh keys in the back-end Hashtable.

Andrew n marshall
  student - artist - programmer
    http://www.media-electronica.com/anm-bin/anm
      "Everyone a mentor, Everyone a pupil"