Re: [xml] Release of libxml2-2.4.21

[Aleksey Sanin <aleksey aleksey com>]

If the client wants to provide special handling for http://, ftp:// or 
any other protocol
then it have to know how to implement the callbacks from xmlIO.h anyway.
From logical point of view, the rules for reading XML and binary files 
could be different.
One for example, can decide that XML files should be automatically 
compressed
with Zip, not GZip. In the solution I suggest there will be two set of 
handlers:
for XML files and for binary files. In most cases, the client will 
implement them once
(because the interface is the same!) and simply call two different 
"callback regisrtation"
functions. I do not see a big hassle here.
I agree with you that these functions are internal for LibXML and in 
normal case
they should not be open to the public (i.e. normal clients should not 
use these functions).
I have a special case since I am building another library on top of 
LibXML. The simplest
way for me is to copy xmlIO.c into my tree and use this functions 
internally. But I do not
want to create two copies of the same code (code reuse, maintanance, etc.).
The proposed change is a "close integration between two products" :)


Aleksey.


> Doesn't this require that the client knows and understands about the source
> of the information and perform URI processing for itself ? Would it not be
> better to provide a single entry point to read raw data without the
> post-processing that you mention.
>
> Looking at xmlInputBufferCreateFilename I see that it matches the first
> element it can and then initialises that with an opencallback call. Could
> this routine not be cloned as xmlInputBufferCreateFilenameWithoutGZip
> and to check explicitly for the gzip handler and if found just skip it.
>
> This would reduce the extra exported symbols to just one and make for a
> simpler interface for clients. I don't know what support the HTTP and FTP
> libraries have there, but it seems to me that the only support for gz files
> is that in the file: scheme. Checking for and ignoring the gzip entry would
> be a special case (I realise and understand) but it would make for a cleaner
> external interface.
>
> This is on the understanding that the only special processing you are
> thinking of is the ungzip that happens for file: URIs. If that's not the
> case, then I'm on the wrong track.