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

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



On Wed, Jun 02, 2004 at 05:58:49AM -0400, Rob Richards wrote:
> 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?

  can you make a monimal patch on top of the previous one ? It's very small
but being back after 6 weeks on the road I have a huge pile of TODOs and
every little bit helps,

  TIA,

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/



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