[xml] Feature request: callbacks


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.


----- 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 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]