Re: Request: Test suite for EFS.

[Kent Schumacher <kent structural-wood com>]

Norman Stevens wrote:

> On Thu, 24 Feb 2000 u07ih@abdn.ac.uk wrote:
>
> > > I suspect that this is fairly impossible without knowing what the intended API is.
> >
> > efs_open, efs_close on a compound file
> > efs_file_open, efs_file_close (read, write) etc on a file within the compound
> > file. Other things like efs_stat efs_opendir efs_readdir
> >
> > The api seems pretty simple really if you understand the unix file stuff.
> >  All the efs things are in bonobo/libefs.
> >
> If the abstraction is good enough then we could implement all the
> proposed ideas as implementations of that abstraction, i.e. offer
> the user the choice of saving as efs, tar, directory, whatever.
>
> I'm just wary of a new binary format which is merely a reimplementation
> of existing code.
>
> Norman

I just did a quick look at the code and it looks like the FILE* like handle
returned from a efs_open contains a pointer to a driver structure which
in turn contains pointers to open, close, read, write, etc.. functions.

I'm guessing that the file name passed to efs_open is a colon (:)
seperated string composed of filesystem-filename, embedded-filename,
and driver.  Possibly something like this /data/compdoc.efs:/tmp/cia.txt:fsys.

I think you can choose the driver by appending a colon prefixed string to the
filename (i.e. fsys) or the efs_open call will autodetect what it is opening,
although all these conjectures are based on about a five second look at the code.

The internal path can refer to a directory, in which case you can iterate across the
directory entries.

My conclusion is that EFS can be made to read or write a binary compound doc, tar file,
xml file, etc...

It looks good to me.
Kent