[xml] Feature request: callbacks

[Uwe Steinmann <steinm majestix fernuni-hagen de>]

Hi,

I had a short discussion with Daniel about the need to have callbacks,
when nodes are being deleted (see below).

Is there any objection for such a feature.

  Uwe

----- Forwarded message from Daniel Veillard <Daniel Veillard imag fr> -----

Date: Thu, 15 Mar 2001 08:51:24 +0100
From: Daniel Veillard <Daniel Veillard imag fr>
To: Uwe Steinmann <Uwe Steinmann FernUni-Hagen de>
Cc: Daniel Veillard <Daniel Veillard imag fr>
Subject: Re: libxml: attach userdata to xml node
Reply-To: Daniel Veillard imag fr
User-Agent: Mutt/1.2i
In-Reply-To: <20010315090655 A4870 gehtnix fernuni-hagen de>; from steinm majestix fernuni-hagen de on Thu, 
Mar 15, 2001 at 09:06:55AM +0100

On Thu, Mar 15, 2001 at 09:06:55AM +0100, Uwe Steinmann wrote:
> On Tue, Mar 13, 2001 at 02:34:10PM +0100, Daniel Veillard wrote:
> > [ Cc'ing Paolo, this is about PHP4 DOM implementation , based on libxml2 ]
> >
> > On Tue, Mar 13, 2001 at 03:27:34PM +0100, Uwe Steinmann wrote:
> > > > One of the important point is that you need to make the memory management
> > > > of attached blocks. Libxml don't even look at it.
> > > What about calling a user function which is called if a node is destroyed? 
> > > If nodes are freed recursively the application should be somehow informed
> > > to make sure the private data is freed as well.
> >
> >   Well so far my experiment with it proves it would not be
> > a good API. I may associate different type of _private fields
> > depending on the nodes (I actually do this in libxslt). Also there might
> > be no reason to free up the associated data when the tree is destroyed
> > I can think of at least 2 good use case:
> >   - XML protocols where the data are generated to the serialization
> >     but should not be destroyed once one et rid of the message
> >   - when building a browser, the rendering associated should not
> >     be destroyed when the tree data is (lesson learnt in Amaya ...)
> > So basically if you define data associated to the tree is might be
> > simpler to free them at your level.
> > But this said i'm not totally opposed to add this, the API is already
> > kindof bloated, and it should not be too hard to implement ...
> I though about it again, and can't see in my application a way to tell
> what can be deleted. Probably because the libxml tree and my own try
> of php objects are too closely linked to each other.
> What I currently do is, whenever an xml node is first accessed, I create
> an associated php object and put a reference to it into the libxml node.
> Parsing a document, which creates the complete libxml node tree, does create
> on the php side just one object.
> The next access onto the same node just returns a pointer to the php object
> and increments the internal reference counter of the object.
> If a node is unlink and there is an associate php object, this has to be
> unlinked and freed. As long as the unlinking is not done recursive by libxml I can
> take care of it, but libxml does recursive unlinking and freeing memory.
> The consequence is, that xml node with associated php object are deleted
> without any notice to my application. Those php objects remain existent
> until the php skript finishes.
>
> I used to have a different approach where the complete node tree has been
> build with php objects when parsing the document and the libxml document has
> been freed afterwards. The disadvantages is, the functions like dumpmem
> or adding new nodes can't be used from libxml anymore.
>
> In so far I would like to see a way to add a user function to each which
> is called when the node is unlinked (freed).

  Okay could you forward this to the mailing-list ? I would like
a minimum of review before deciding the API, so that I don't have to change
it in one month because we missed such or such use case ...
  If we start adding callbacks on tree changes, then we must design them
cleanly !

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

----- End forwarded message -----

-- 
  Uwe Steinmann fernuni-hagen de
  Tel: +2331 987 4528    Fax: +2331 987 375