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

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?


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