Re: [xml] A generic way to add user data to nodes?

[Simon Berg <ksb nada kth se>]

> > > > > "Daniel" == Daniel Veillard <veillard redhat com> writes:

    Daniel> On Thu, Jan 10, 2002 at 02:45:40PM +0100, Simon Berg
    Daniel> wrote:
    >> Hi, everybody
    >> 
    >> I feel that it would be useful if libxml had a generic way to
    >> add user data to nodes. Right no fighting over the _private
    >> field or using external lookup tables seems to be the only
    >> options.

    Daniel>   Fighting over ? Why ? this field is left to the
    Daniel> application for use.

If I'm using a another library that uses _private (like libxslt),
there's nowhere I can store data specific to my application in the node.
Right?

    >> Using the content field to store line numbers also seems a bit
    >> awkward.

    Daniel>   Yes, but I didn't found any other way to add it without
    Daniel> breaking clients API and bnary compatibility.

    >> This is my suggestion how a solution might look:
    Daniel> [...]
    >> The _private field is used to point to the first user data
    >> object.

    Daniel>   This is an access convention. Since the field is left to
    Daniel> the user program that convention could be followed or
    Daniel> not. In that case why try to impose it ?

This mechanism uses this field since it's the only one free.  You can
think of it as a way for different parts of a program to coordinate
their use of _private .

    >> The xmlNew* functions would have to be changed to initialize
    >> _private to NULL.

    Daniel>   No they already do. Well they should. If it's not the
    Daniel> case it's a bug.

Sorry, missed memset.

    >> xmlFreeNode needs to call the release method on all attached
    >> user data objects. Should the release callback be called on all
    >> super classes too, like a C++ destructor?

    Daniel>   Hum,

    >> xmlCopyNode should call the copy method on all attached data.

    Daniel>   I can perfectly see case where this should NOT be
    Daniel> done. For example _private is used for node key indexing
    Daniel> in libxslt and a copied node should not be considered as a
    Daniel> keyed node. User level semantic !

That's why it's a callback. If you don't want copying, make it a no-op.

    >> There are probably other functions that need modification too.
    >> 
    >> How does this work with threads?

    Daniel>   requires user level locking like every other tree access
    Daniel> function.

    >> What do you think? Is this a good idea? In the long run it
    >> would require to rewrite some amounts of code, but I still
    >> think this kind of solution is the way to go.

    Daniel>   Unclear to me. I have considered it, and while sometimes
    Daniel> I would like an extensible framework, I also hate
    Daniel> over-engineering and it's unclear to me this is really
    Daniel> needed. Anyway this would have to be pushed to a later
    Daniel> binary incompatible revision I'm afraid.

It's possible to keep binary compatibility and still let applications 
enable this if they want to.

    Daniel> Daniel

simon