Lists Home |
Date Index |
- From: John Totten <email@example.com>
- To: David Megginson <firstname.lastname@example.org>, email@example.com
- Date: Tue, 01 Sep 1998 23:35:30 -0800
Take some time to review this little item.
I have been playing around with this and would like to link it to a DOM
parser so that the tree was built in a persistence store rather than
memory. Being dynamically configurable makes this an ideal vehicle for
doing this. You could thereafter deal directly with the object store or
even just the view (indexed into the store) and not repeatedly reparse
the document. It also removes any limits on the size of the document
that you could parse in a single pass.
If anyone succeeds in doing this then I let me know please.
David Megginson wrote:
> John Totten writes:
> > > With a naive tree implementation, a 10MB document might use 100MB
> > > or more of virtual memory for the document tree -- that'll bring
> > > most current desktop systems to a screeching halt.
> > Do you mean 100MB for the stack of parsed treeview objects as
> > opposed to the GUI toolkit. And if so then why does it take so much
> > space when all it takes is the addition of the parent ID to the
> > serialised data item?
> I don't recognise some of your terminology -- perhaps it is
> MS-specific. In general, the GUI should not add significantly to the
> storage requirements (especially with an MVC architecture, like the
> one used by the Java Swing components) -- what takes up the room is
> the tree of nodes representing elements, attributes, character data,
> All the best,
> David Megginson firstname.lastname@example.org
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)