Re: [xml] Feature request: callbacks

[Daniel Veillard <veillard redhat com>]

> ahmm ... robert pointed that out in his email ... let me sum it up as i see this: 

  No I don't see anything in robert's mail which follows that scheme,
maybe i missed it...

> having a callback structure at node, document and application-level like:
> 
> struct {
> 	int xmlCallbackStackLevel;
> 	void * xmlTreeChangeCallbackStack[];
> }
> 
> whereas the first pointer registered in xmlTreeChangeCallbackStack at node-level
> would be the callback-handler for the document-level and the first pointer registered 
> at document-level would be the callback-handler for the application-level
> and the first pointer registered at application-level would be libxml's own handler
> or NULL whichever is preferable
> 
> if a node is changed/deleted/.... the callbacks are called in descending order
> on the node, the first callback of the node then calls all the document-callbacks
> etc, etc ...

  Honnestly I'm not found of it:
   - it's complex, and I don't see why this complexity is required.
     It's time to show up a really convincing example...
   - testing whether a callback and what callback should be called
     is complex, and that's an operation which is likely to happen
     in a number of speed critical places
   - even I have trouble understanding how it is supposed to work,
     I'm afraid of the consequences for application writers.
   - the per-document or per-node callback is not dependant on the
     node or de document to which this applies, so what's the use
     of such a switch (if if has to be node dependant, this mean
     adding one more pointer to the node structure and I say NO
     in advance) ? I think this swicth is better located in the
     application handler.

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/