Re: [xml] xml and IO

On Thu, May 31, 2001 at 04:31:34PM +0100, Gary Pennington wrote:

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

  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 Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

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