RE: Level 2 iterators

Arkin wrote,
> While implementing the code, I learend some important 
> issued. First, it is possible to create a non-live 
> iterator that is very efficient only using the DOM 
> API. That iterator can be made to work with any DOM
> library very efficiently. The point I'm making is that 
> there is no need to extend Document in order to use 
> non-live iterators, and an application may provide and 
> use it's own iterator for that matter.

Indeed. However, the current draft rules out the
possiblity of any such iterator implementing the
NodeIterator interface. The upshot is that any future
APIs defined in terms of NodeIterators (whether standard
or proprietary) will be forced to either: live with the
performance characteristics imposed by the need to
perform fixup; or work directly with Node's parent,
child and sibling operations. The first option will be
impractical in many cases. The second is really rather
a shame ... a standard iterator interface with broad
applicability would have been a real gain.

> Assumption:  CPU performance is everything
>
> Reality:  In some applications you may want to go the > extra mile to make
sure the CPU is utilized to the 
> max; but most of the time, if you can develop it 
> faster, test it less and run it more reliability, you 
> have gained performance and efficiency that surpasses 
> raw CPU utilization.

But this isn't about developing a one-off application.
It's about designing a standard API on which many
applications will depend. The usual RAD arguments don't
apply here.

> Assumption:  The DOM API should define all operations 
> that work on a document tree
> 
> Reality:  The DOM API should only define basic
> operations that can only be provided by a DOM 
> implementation, and not by 3rd party code. Anything
> that can be written efficiently without relying on the 
> DOM implementation, can be provided by the 
> application. Anything that can be done differently 
> (faster, or otherwise) in a specific application,
> should be provided as an optional feature by the 
> library provider.

Agreed, but then my argument with the draft boils down
to an issue of what the correct selection of basic
operations is. My view is that live NodeLists and
NodeIterators with fixup, whilst possibly helpful to the 
less experienced, or pressured, programmer are high-
level constructs rather than basic functionality. I
accept the argument they the spec should provide them.
But they should be in addition to a well chosen set of
primitives, not a substitute.

Cheers,


Miles

-- 
Miles Sabin                          Cromwell Media
Internet Systems Architect           5/6 Glenthorne Mews
+44 (0)181 410 2230                  London, W6 0LJ
msabin@cromwellmedia.co.uk           England

Received on Friday, 5 March 1999 11:01:59 UTC