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

[Daniel Veillard <veillard redhat com>]

On Tue, Jun 01, 2004 at 06:24:57PM -0400, Rob Richards wrote:
> Here is the completed patch which will allow custom implementations of the 
> xmlParserInputBufferCreateFilename and xmlOutputBufferCreateFilename functions. This allows the 
> capabilities of isolating an app from the I/O callbacks.
>
> Hopefully this is the correct solution to the issue.

  Okay, I finished reviewing it, and applied it, runs the 
regression tests, looks fine. I will commit it soonish.

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() ,

  what do you think ?

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/