Re: [xml] Feature request: Pop Callbacks

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
open_1 # results in more XSLT
# install new callbacks here for next level of XSLT
# want read_1 here, but instead we get:

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.


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