Re: [xml] Feature request: Pop Callbacks

[Daniel Veillard <veillard redhat com>]

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

  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

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/