Re: [xml] Release of libxml2-2.4.21

[Justin Fletcher <justin fletcher ntlworld com>]

In message <3CCE3BD8 1000608 aleksey com>
          Aleksey Sanin <aleksey aleksey com> wrote:

> > But I think we can start relaxing the constraints w.r.t. adding API
>
> Well, in this case I have a request :) First let me explain the reason
> why I need this. The problem I have in XML Security Library is that I need
> to read not  only XML files but binary files as well (for example, when I
> need to sign or encrypt a  plain vanilla binary data). The XML data input
> callbacks used by LibXML could not be  used for reading binary data
> because one can decide to do some special processing  (like automatic
> gzip) for XML files. And this processing should not be done  for binary
> files. The solution is to have custom handlers for processing binary files
> as  it is done for XML files. The only problem I have is that I am lazy
> and I do not want to duplicate  10+ static functions defined in xmlIO.c :)
> And this is bad from code-reuse point of view. So my request is: can we
> remove word "static" from the following  functions in xmlIO.c and copy the
> declarations to xmlIO.h?
>
>     xmlFileMatch
>     xmlFileOpen
>     xmlFileRead
>     xmlFileClose
>
>     xmlIOHTTPMatch
>     xmlIOHTTPOpen
>     xmlIOHTTPRead
>     xmlIOHTTPClose
>
>     xmlIOFTPMatch
>     xmlIOFTPOpen
>     xmlIOFTPRead
>     xmlIOFTPClose

[snip]

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.

-- 
Gerph {djf0-.3w6e2w2.226,6q6w2q2,2.3,2m4}
URL: http://www.movspclr.co.uk/
... Eyes to the heavens, screaming at the sky;
    Trying to send you messages, but choking on goodbye.