Re: DOM Level 1 Becomes a W3C Recommendation

Mike Champion wrote:

> At 02:17 PM 10/1/98 -0400, John Cowan wrote:
> >msabin@cromwellmedia.co.uk wrote:
> >
> >> What's wrong with a documented precondition for the
> >> method? That's been deemed good enough in all the
> >> APIs I've ever seen. How much hand-holding do DOM
> >> users need?
> >
> >DOM Level 1 is all *about* handholding.  That's why NodeLists
> >and NamedNodeMaps and HTMLCollections have to be live, because
> >the users of Level 1 aren't believed to be smart enough to
> >figure out when to refresh them.  The assumption is that amateurs
> >will be creating programs (typically in scripting languages)
> >that edit DOM documents, and we can't allow them to create
> >data structures which will cause other DOM methods to malfunction.
>
> Very well put, and you're right -- for Level 1, we assumed that DOM users
> would need lots of handholding.  It's unfortunate that this causes so much
> overhead for those who don't need handholding and don't want to pay the
> overhead, but remember that Level 1 was driven mostly by the PRESSING need
> to get Netscape and Microsoft to play nicely together.

It depends upon your implementation.

IMO, the live list means that implementations do not have to incur the extra
overhead of fully evaluating the list so that they can be much more efficient
for advanced users who don't need the hand-holding to deal with
synchronization issues.   IMO, the amateurs are the ones who aren't willing to
synchronize and want to force the extra overhead on every list creation.

Or perhaps someone can explain how to lazily evaluate a stale list that
doesn't give a skewed snapshot of the data, with very bad possible
irregularities.  Implementing the live list was very efficient compared to a
stale list evaluated at creation time.  All you need to do is dump the cache
if the document changes.  Good implementations can get much more precise about
cache dumping if this is a common occurrance -- but it isn't if
synchronization is employed.

Those who think a stale list evaluated at creation time solves their
particular synchronization problems (I don't) and is justifiable as
handholding overhead (I don't) should incur the overhead themselves to
synchronize and copy to a static list without forcing those who solve the
problem through other, often superior, forms of synchronization to incur the
extra allocation and overhead.

My DOM implementation is used on the server and cannot afford this unnecessary
overhead.  If I ever want a static snapshot, I'll incur the processing and
memory overhead explicitly and do lots of extra work so that the stale nodes
will not cause problems.  But usually there are better alternatives, and the
cache never needs to get dumped at all.

A better solution would have to involve iterators, but again, that is for
better hand holding so that the user doesn't have to worry about when the list
shifts.  It won't improve efficiency over a well-implemented live list
(although, like live lists, it would be an improvement over static lists).

Ray Whitmer
ray@imall.com

Received on Friday, 2 October 1998 13:51:26 UTC