[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: plan for lightweight DOM implementation
From:       Ariya Hidayat <ariya () kde ! org>
Date:       2005-11-02 15:38:57
Message-ID: ba035dd10511020738i7a6124c3r4a0ab06284d0674c () mail ! gmail ! com
[Download RAW message or body]

> Basically, it would work like current DOM stuff works, with one
> exception. The code which uses the DOM stuff will be able to provide a
> list of tags, for which lazy evaluation is desired (as a list of
> names). Note that this would also affect all nested tags within a tag
> with a given name. Then, the file would be loaded all into memory and
> stuff, as it is now, but whenever the tag in the list is encountered,
> parsing would stop until the matching closing tag comes (so some
> parsing is necessary to avoid problems with nested tags having the
> same name), and a proxy node will be created, that'd point to a
> position in the file or loaded strem or something where all contents
> of the tag and its childs are written (or alternately, it could be
> stored in the proxy tag as a big string). Then, when the code wants to
> use the tag, it would transparently (or the code would call some
> method, like wantToUseTag) parse the XML section into the DOM subtree.
> And after processing, the code would call something like releaseTag,
> which would release tag contents. This releasing could maybe work also
> for tags that were loaded normally, without using the lazy-loading...

I'm afraid I don't full understand what you mean here.
Also, I suppose there is no need to give list of needed tags to the
new DOM stuff as it is intended as drop-in replacement for QDom
classes (at least for KOffice case). The only addition is
DomNode::unload() method so that the application can explicitly
release the memory taken by nodes which are not of interest anymore.
In the future, when age-based cache is implemented (as suggested by
Thomas), this method is even not needed anymore.

> I believe that this would be quite straightforward to implement,
> possibly simply by copying QDom and making the necessary changes...

After scanning qdom.cpp for many nights, I still can't find a way to
make it as straightforward as it could be. For starters, its
referenced-based API makes it not easy to introduce new functionality
through subclassing.

Thank you for your feedback !


--
Ariya Hidayat, http://ariya.blogspot.com
http://www.google.com/search?q=ariya+hidayat&btnI
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]