Re: RE: problem with user_data

On 4 Apr 2002, John Palmieri wrote:

> Gdome but I am assuming nodes are derefrenced and then reloaded when a
> user visits it again.

I don't understand well what you mean by "reloading".

Gdome works on two layers: the lowest layer is the libxml2 tree
structure. This tree represents the structure of the document. On top of
it there is the proper gdome layer, made of wrapping structures, one for
each node at the lower layer. Despite libxml2 nodes, gdome wrappers are
allocated only when necessary (e.g. when the user is accessing a node).
In no case the libxml2 nodes or gdome2 wrappers are ever swapped to disk
(or serialized), unless you save the whole document back to disk. In this
case the corresponding XML document is created (it can be considered as
the serialized version of the tree structure).

The problem we were facing in december was *not* the serialization of user
data possibly attached to tree nodes. It was about the fact that since
gdome wrappers are allocated/deallocated as you reference/dereference
them, and since the user data field is stored in the wrapper, you might
loose the content of the user data field if you don't keep a reference to
the node where you registered the data.

The problem you are describing is indeed a real problem, but only if you
think at serializing the information stored in a DOM tree (or a fragment
of it) together with information possibly stored in the user_data
field.

To this respect, the solution you propose makes perfect sense, and it
follows indeed the same ideas of the UserDataHandler (see DOM level 3
core, working draft).

> backwards compatable.  Instead of putting the function pointers for load
> and unload in an inheritable struct they can be placed within the node
> object and if not set to null run at the appropriate times. 

this would also increase the memory occupation for each node by 8 bytes on
32 bits architectures. I think that if the DOM level 3 will ever be
implemented in Gdome2, we will have to redesign wrapping structures so to
optimize memory management. Just adding fields is not going to be a
feasible solution, as already now memory occupation is a major issue for
gdome2.

Cheers,
luca