[gdome]problem with user_data

[Luca Padovani <padovani scl csd uwo ca>]

Dear Gdome2 users,

the following is a kind of bug/feature of gdome2: as you probably know,
every gdome2 structure has a field (which is the only public field) whose
name is user_data, which can be used by the user to store some information
associated to the node. This is much like the _private field in libxml2
structures.

However, the field user_data is stored within gdome2 wrapping structures,
and this basically means that when the gdome2 wrapper is deallocated, the
information is lost without notification. So the question is: how does
gdome2 decide when to deallocate a wrapper: currently, two conditions must
be satisfied:
a) the reference counter must be zero (obviously)
b) the list of event listeners must be empty (that is, nobody registered a
   listener on this node)

Thus, if you ask for a node, store something in user_data, then move
around without keeping a reference to it, and then return back to it, the
stored information will likely be lost (and you'll have NULL in
user_data).

Would you consider this a major problem to be fixed eventually? Currently,
all our projects storing data in gdome2 wrappers are such that they also
keep a reference to the node itself, so we were wondering if this was the
case in most/all situations. If not, the changes to fix this might be
quite extensive, and must be carefully designed.

Among possible solutions (in increasing order of effort required to
implement them):

0) pretend that the user keeps a reference to all the nodes where
   information has been stored
1) never deallocate gdome2 wrappers, once they've been allocated, until
   the document is in memory.
2) access the user_data field via a method, so that upon setting it a bit
   can be stored somewhere indicating that there is information there, so
   the wrapper cannot be deallocated. However, a new method must be
   provided to "reset" the data there (and the corresponding bit)
3) change gdome2 wrapping structures so that they're just a pointer to the
   libxml node, a reference counter and a list of generic "properties",
   each property being a pair (name,value). Properties can be "user_data",
   "event_listener", "read_only", etc. This might be an advantage if the
   average number of properties stored per node is very small, and given
   reasonable default values (for example, for "read_only" the default
   could be false).
   Such lists would grow as needed.

At this point we'll just wait for your feedback.

Best regards,

	luca