[gdome]future memory management plans? (was: News(2) on CVS preparing 0.7.0)

[Tobias Peters <t-peters gmx de>]

On Mon, 5 Nov 2001, Paolo Casarini wrote:
> Next tasks:
>   - Work on possible memory leak

Dear Paolo and other list members,

my impression is that the new memory management works as intended: gdome2
now knows when to delete libxml's tree structure. There is another problem
that did not think of when we dicussed about the whole memory management
issue: It does not know what to delete.

Sure, the libxml tree structure beneath the document node is deleted at
this point in time, using xmlFreeDoc, but let me cite from the DOM 2 Core
recommendation:

"In the DOM, documents have a logical structure which is very much like a
tree; to be more precise, which is like a `forest' or `grove', which can
contain more than one tree."

The other trees can be subtrees cut off the main tree with removeChild,
subtrees copied with cloneNode, or Nodes created by Document's
createSomeNode. These are not deleted by xmlFreeDoc.

The conclusion is to me that it is not enough to keep track of living
nodes at the document level. In addition to the document level, this has
to be done at the tree level, too.

I think this is difficult to implement on the current code base. So I want
to ask you people on this list, and the maintainers of gdome, how you're
regarding this issue.

You may think of user applications that load, manipulate, and save far
less than 10^2 documents per session. For these applications, the memory
leak caused by some nodes that are removed from the tree by user editing
may not be worth thinking of.

The reason why I am currently concerned with xml and dom at all is because
I want to use xml documents in a network protocol, possibly leading to
10^2 documents manipulated per minute in a server process that should run
for several months. It becomes a problem on that scale.

Maybe gdome2 is simply not the right tool for me. I intend to write a
simple libxml wrapper in ruby, based on a thin c++ tree memory management
layer that I wrote this week; and use that instead.

Bye, Tobias