Re: [xml] Feature request: Pop Callbacks

On Tue, Apr 20, 2004 at 08:33:02PM +0100, Matt Sergeant wrote:
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.

  Okay, so you want to do dynamic registration/unregistration.
In that case pop might be useful, well its simple to add. The main change
would be to increase the maximum size of the stack as you noted it is
currently limited to 15 which is a bit short for this, though I'm not
sure I really want to let the stack size to increase dynamically.


Daniel Veillard      | Red Hat Desktop team
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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