- From: Gavin Thomas Nicol <gtn@eps.inso.com>
- Date: Tue, 28 Jul 1998 11:37:30 -0700
- To: "Stephen R. Savitzky" <steve@crc.ricoh.com>, "Mike Champion" <mcc@arbortext.com>
- Cc: <keshlam@us.ibm.com>, <www-dom@w3.org>
> I'll stand by my original statement. For example, consider a document > derived in the obvious fashion from a table in a relational database. A > node with several million children is not unreasonable to expect. If the > document is ``live'', the implementor might have to query the database and > obtain the entire table at each iteration. > > It might not be obvious now, but people are going to be using the > DOM for a lot of things besides hacking flashy effects into a document in Netscape. > > > Nevertheless, the real answer -- as I think you said last time > -- is to put interators back in the spec for Level 2. > > You're right there, but even iterators don't help if they are > required to be ``live'' and constantly reflecting the current structure of the tree. > Sometimes that interpretation is the correct one, sometimes it isn't, and > either the determination should be left to the implementor, or > two different > subclasses of iterators should be specified. Inso often deals with document exceeding 10MB, and in fact, it is very common for us to deal with 100MB+ documents. I can tell you that I was one of the people screaming very loadly about "liveness". That said, I think the easiest way to take care of liveness is to add a locking mechanism in level two. That way, you can *preclude* people from messing with the tree when you don't want them to: just build the tree, lock it, and then liveness is a non-issue.
Received on Tuesday, 28 July 1998 11:38:40 UTC