RE: An observation about "live" NodeLists

Ray Whitmer wrote,
> 1.  Our implementation directly implements children as lists, 
>     so this is not an issue when processing child lists.  At
>     most, we only ever need one NodeList per node, which
>     never get fixed up artificially.  So they never pile up 
>     in the first place.
> 2.  getElementsByTagName is not something we call much on the 
>     server for long-lived documents, because for documents
>     which stay around for a long time, we build advanced
>     indexes for them so we can find things in them quickly.
> 3.  Our stress tests have been quite artificial.  We will be 
>     going live within the next month or so.
> 4.  If we ever did forsee a use case that might stress test 
>     it, I would quickly build indexes.

In this context of this thread, I find these points a bit
puzzling.

Could you explain to me what the difference is between, for
example, an index of P elements and, if it was allowed by 
the DOM spec, a static, unsynchronized, NodeList over P
elements?

The reason I'm puzzled is that unless I've misunderstood a
lot of what you've been saying, you've been, on the one hand
advocating dynamic NodeLists over static NodeLists on the
grounds that they can be implemented efficiently, and that
static NodeLists are error prone; on the other, you're not
actually using dynamic NodeLists very much, but you are
using things that sound a lot like static NodeLists.

Err ... this is not a troll ... I really want a bit of
clarification because the issue is quite important, probably
to most readers of this list.

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 Wednesday, 21 October 1998 05:10:32 UTC