Re: Level 2 iterators

Miles Sabin wrote:

> The increase is in complexity in the big-oh sense ...
> that is, fixups (and even notifications of invalidation)
> have serious performance consequences, either for
> next/prevNode(), for tree mutation operations, or both.
> For those of us wanting to use the DOM on the server-
> side this is a serious issue, and would probably rule
> out the use of iterators in the same way that it now
> rules out the use of NodeLists. Worse still, it could
> also rule out the use of current or future APIs that are
> specified in terms of NodeIterators.

I currently use NodeLists in very high demand server code.  It all
depends upon the efficiency of the DOM implementation and the specific
use cases.  I tend to use NodeLists mostly in documents which don't
mutate until after I stop using the NodeList.  While I might think up
specific use cases that would rule out this or many other DOM
techniques, they are far from automatically ruled out.

> But it doesn't have to be this way. NodeIterator is an
> interface, and as such can have implementations with
> differing characteristics.

Agreed.  But behavior is an essential guarantee of an API.  Let's say I
make a method which accepts a DOM node iterator as an argument, and
replaces the nodes encounter on the iterator.  If I know how iterators
behave in a live situation, I can generally use any iterator that is
handed to me.  If I do not know, then the iterator is fairly useless to
me.

This is the flaw in an iterator API which makes no effort to behave in
some standard way.  And depending upon what your underlying model is,
the "standard way" you might want some economized iterator to behave
will also vary.  Some people seem to assume that everyone else agrees
that their way is the most efficient possible DOM implementation.  But
there are many tradeoffs and many possible choices for either the client
or the server.  Your "efficient" behavior may be fairly inefficient for
another implementation or use cases.

You have to make sacrifices for interoperable code.  Just because the
DOM supports certain ways of doing things interoperably, doesn't mean
that you shouldn't, in extreme cases, make a proprietary implementation
that will work better by marrying your use cases and your underlying
implementation better.  Proprietary APIs which are designed around a
single implementation will generally be more efficient and sometimes
greatly so.

> The spec should be amended
> to allow for more lightweight implementations (currently
> it can only be read as requiring that any and every
> NodeIterator implementation support fixup), even if the
> default implementation behaves as currently described
> for hand-holding purposes (however spurious).

Although I once advocated this, I now believe that implementations which
behave differently from the stated spec should implement a proprietary
interface, not a w3c dom interface.

It doesn't achieve much if you say at the end of the day, "well, isn't
it great that I used the DOM APIs everywhere".  But then you try
plugging in another DOM and the iterator behaviors are all different so
that all the users of iterators get unexpected behaviors.  It should be
a proprietary interface to start with so that at least it is clear up
front that the two iterators are not interchangable even if the method
signatures happen to be the same.

That's my opinion, anyway,

Ray Whitmer
ray@imall.com

Received on Thursday, 4 March 1999 15:07:17 UTC