Re: [xml] patch: custom I/O BufferCreateFilename handlers

["Rob Richards" <rrichards ctindustries net>]

From: Daniel Veillard

> My main concern is that given a stack of modules using libxml2,
> for example within an Apache process, only one *per thread* can
> reroute the I/O, ideally there will be no conflict because
> conflicting extensions will be running on separate threads.
>   However, I understand the work of a new plugged routine
> to check the URI given the callback to check the I/O
> for direct handling by the module. Where I'm annoyed is if the
> URI is not understood, because it was generated by another
> libxml2 client in the stack within the same thread, then
> you're stuck. I think one easy way to try to cover
> this is to allow chaining:
>   - when registering an handler, keep the previous handler
>     (__xmlIn/OutputBufferCreateFilename if NULL)
>   - if a module is fine allowing chaining, then instead of returning
>     NULL it should first call the previous handler
>   - on shutdown it should restore the previous handler
> I understand you may not want chaining specifically for your
> case, but still the extension should allow it. It does everything
> for it except the handling of the default handling. There is no way
> with the current state of the patch to get at the original default
> behaviour of __xmlIn/OutputBufferCreateFilename . The only change
> I would suggest on top of this is to never return NULL from
> xmlParserIn/OutputBufferCreateFilenameDefault() ,

Yup. I agree 100% with what you are saying here. Was actually thinking the
same thing last night and going to bring that up today as I could also see
cases where you might need to first test your I/O handling and if you cant
handle it then default back to the origional handling, while other times you
might not want to allow the chaining which you arent forced to do.

Are you going to throw that in or do you want me to do another patch?

Rob