Re: [xml] xml and IO

[Daniel Veillard <veillard redhat com>]

On Thu, May 31, 2001 at 04:31:34PM +0100, Gary Pennington wrote:
> Hi,
>
> I'm trying to add a mechanism so that any files which I open using
> libxml are locked (to prevent anyone else tampering with the files as
> long as my process is running). I'm attacking this problem by:
> 1. Defining 4 routines for match. open, close and read.
> 2. Adding the required code for open and close to lock and unlock the
> file.

  okay, sounds the right way.

> Since I don't do anything special with the file (other than lock and
> close) I'd like to piggyback my code onto the existing default file
> handling functions (xmlFileOpen, etc...). However, the existing file
> handling functions are all defined as static.
>
> I could copy the code from these functions into my routines and solve
> the problem like that, but I don't like that approach since it is
> intrinsically naff.

  Well xmlFileOpen and Co. are fairly small. In this kind of cases 
I'm not too afraid of duplicating a bit of code.

> Would it be such a bad thing to make these various IO functions part of
> the public interface so that people can easily utilise their
> functionality? I know that it's a good idea to keep implementations
> private where possible, but since the IO registration mechanism doesn't
> support cascaded IO handling (where a number of qualifying IO functions
> can all be registered) it makes sense to make these "default"
> implementations available.


  Well this part is relatively stable. Opening it should be no big trouble,

> Either that or let multiple IO handlers
> register to handle IO's of certain types.

  Well that can start to get nasty ... you would have to manage ordering,
possibly cascading etc ... I would prefer to keep the I/O registration
system simple.

> I know that the file handling routines don't do a lot, but it would be
> more of a pain if you were trying to do the same (conceptual) thing for
> ftp or http or whatever handlers.

  That's right .

> OR am I attacking this problem in completely the wrong way? Is there
> already some other easy mechanism for doing this that I haven't spotted?

  No, your analyze is fine. It's a trade-off, I don't have strong opinions
and may well balance in the side of a provided patch making the I/O 
handlers public.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/