Re: [AD] Clarifying and revising filesystem API

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2009-04-17, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> Peter Wang wrote:
> >>
> >> al_set_default_stream_handler(ALLEGRO_FILE_VTABLE *vtable);
> >>
> >> Passing NULL would reset to the builtin one.
> > 
> > I'm not particularly opposed to it, but I don't think prepending is that
> > hard, using al_ustr_newf() for example.  What cases are you thinking of?
> > 
> 
> Still hard enough. And I need to do it for every file I load - setting the 
> default handler I would do only once at the start of my loading function.

I thought normally you'd load files in a loop, in which case you only need
to prepend in one wrapper function.  If you're loading files individually
(for a test program), you could just write the prefix in the string literal.

Point taken though.

> I also 
> think it is nicer design in general to not make addons (like physfs) second 
> class citizens by requiring string operations when using them while allowing our 
> builtin stdio to be used without extra string operations.
> 
> >>>
> >> I find this really confusing... when doing it like this, what is the remaining 
> >> advantage of using this over the _entry version?
> > 
> > You wouldn't need two versions of every function, the string version and the
> > _entry version.
> 
> I thought we keep the _entry versions anyway? If they are completely removed I 
> guess it makes more sense.

The only reason to keep them is sometimes (not always) you can use the
_entry versions to read and write files-within-files, like .dat files.  On
the other hand you can achieve the same thing using memory files, if you
don't mind keeping the entire subfile in memory temporarily.

> > Elsewhere:
> >> My vote also goes for directory operations. It's very common in games (e.g. list 
> >> all files in the savegames folder).
> > 
> > Ok.  How about we keep directory operations but in a distinct part of the
> > API?  It wouldn't use ALLEGRO_FILEs and you couldn't hook the functions, so
> > they would only work with the local disk. 
> 
> What's the advantage of this? Returning an ALLEGRO_FILE for each file in the 
> directory makes the most sense. (Remember the problem we solved some time ago 
> where we don't know the UTF8 name of each file/directory, and also should not 
> have to.)

We could have:

    ALLEGRO_FILE *al_fopen_dir_entry(ALLEGRO_DIR_ENTRY *direntry);

Actually, one thing I dislike about the current API is that the types
for open and closed files (i.e. directory entries) are conflated.

> > Then the questions about the
> > current directory would have obvious answers.
> 
> I think there are better ways to solve the current directory problem... in fact 
> I don't see it as a real problem at all.
> 
> Thinking about it, I actually like the current API (even though 
> ALLEGRO_FS_HANDLE is a horrible name compared to ALLEGRO_FILE). But basically, 
> your proposal now kills the whole long-standing idea to have a VFS in A5... I'll 
> need some time to accept that I think...

It's easy to pick out a set of stream operations that will satisfy pretty
much everyone.  We can do that well.  It's much harder to pick out the
directory operations.  Taking PhysicsFS again, if I was going to use that in
a game, I'd rather use it directly with its full functionality than a
cut-down interface exposed by Allegro.

In a lot of cases the directory operations will just make no sense and
implementations just have to make up dummy functions.  The memfile addon
does this, and most compression/encryption addons will too.  Yuck.

Hmm, think about this.  Right now, if you wanted to write an encrypted
file addon with the full directory listing operations, you would have to
duplicate all the directory stuff from the stdio driver.  Otherwise you
have to open up the encrypted file by getting the path out of the
directory entry...

Peter