Re: [xml] Feature request: Pop Callbacks

[Matt Sergeant <matt sergeant org>]

On 20 Apr 2004, at 10:09, Daniel Veillard wrote:

> On Tue, Apr 20, 2004 at 07:39:53AM +0100, Matt Sergeant wrote:
> > The xmlIO InputCallbacks stuff. Currently we have:
> >
> > xmlRegisterInputCallbacks() /* push a callback onto the stack */
> > xmlCleanupInputCallbacks()  /* clear the stack */
> >
> > but nothing to pop one off the stack.
>
>   Okay, I see. Well I didn't really expected this to be dynamic,
> for example this may raise "interesting" multithread issues, sure that
> can be done, but the stack is extremely opaque as is, there is no
> way to name the I/O methods, a Pop implementation is relatively
> trivial, but it would not be a very friendly interface. Do you have
> an use case example ? It seems to me that the API need is not really
> to Pop as in a stack interface but rather to remove a given handler,
> the problem being then to identify it, they have no name at the moment,
> the matchFunc pointer equality could be used for naming. But maybe
> the Push/Pop semantic is really what you need...

OK, here's the usage example:

you have some XSLT that does document('axkit://foo') which calls into a 
custom input callback setup to process the axkit: scheme. But the 
axkit: scheme processing also does some XSLT, which might use another 
set of custom input callbacks. Consider us able to nest this up to 15 
levels deep (up to the current number of InputCallbacks allowed).

What we do is each time we call into XML::LibXSLT we call 
xmlRegisterInputCallbacks() to add the callbacks onto the stack, but if 
we then go through the nesting as above we get the following sequence 
of calls:

# XSLT finds axkit: URI
match_1
open_1 # results in more XSLT
# install new callbacks here for next level of XSLT
  match_2
  open_2
  read_2
  close_2
# want read_1 here, but instead we get:
read_2
close_2

So if we could pop the stack after returning from the inner XSLT stage 
we wouldn't get this problem.

Of course now I've thought about it for a good while it also occurs to 
me that a perl-level solution to this is also possible for 
XML::LibXML/XML::LibXSLT, but I still think a pop would be useful, 
perhaps for others with a similar scenario.

Matt.