[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [xml] patch: custom I/O BufferCreateFilename handlers
- From: Daniel Veillard <veillard redhat com>
- To: Rob Richards <rrichards ctindustries net>
- Cc: xml gnome org
- Subject: Re: [xml] patch: custom I/O BufferCreateFilename handlers
- Date: Wed, 2 Jun 2004 05:59:27 -0400
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]