Re: [AD] file system routines

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On December 20, 2008, Matthew Leverton wrote:
> On Sat, Dec 20, 2008 at 3:13 PM, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> 
wrote:
> > Yup. Users and allegro alike should use them over any other api.
>
> But how extensive is it? e.g., could it be used to open up a wav file
> inside a packfile or a zip file? What would the API look like that?

a zip/pack file extension would have to support that itself by making it "just 
work". Currently the plain stdio handler does not handle anything like that, 
but a zipfile addon certianly could. I'm not certain yet what a zip file addon 
would look like.. I have a couple ideas, one would just take the zip file name 
as part of the path for every open and cache a fixed number of "zip headers" 
internally (no need for an explicit AL_ZIP struct), or it could mimic PhysFS 
(or we just implement a PhysFS backend, and users use either physfs or al_fs, 
or both) by reimplementing al_fs_add_search_path to take a zipfile name and 
attach it to a path name:

al_fs_add_search_path("music.zip"); // archive is treated as a dir in this 
context, music.zip contains music/foo.mp3
al_fs_add_search_path("gfx.zip"); // contains gfx/main.png
AL_FS_ENTRY *entry = al_fs_entry_open("music/foo.mp3", "r");

al_fs_add_search_path can take a dir or an archive and the zip/physfs addons 
should treat them the same, so all the open methods will search the search 
path first, then pwd, for relative paths.


> > Probably. But there are some non "entry" functions that just take
> > filenames, and those would then clash with the others. I tried to make
> > all functions that take an AL_FS_ENTRY to be named with entry in it. If
> > you want to remove the helper functions be my guest.
>
> I haven't really taken an good look yet, it was just something that
> caught my eye. I couldn't think of any way that al_fs_putc() [etc]
> could collide with anything else in a meaningful way.

I know its a little messy function name wise.. I had a grand idea to begin 
with that I slowly whittled away to almost nothing, and it all got mixed up in 
the end. I would like to rename the classic a4 style big/little endian 
functions, something like al_fs_get32l/get32b.

And the al_fs_entry_open function doesn't quite match up with my explanation, 
it doesn't take a AL_FS_ENTRY, it just creates one and "owns" it (a close will 
destroy it, if you don't want that, use the handle functions, the two apis can 
be mixed cleanly).

I am interested in any cleanup ideas people have, and if you're all interested 
in me extending it to deal with ENTRIES a little more, like with 
al_fs_readdir, Id LIKE for it to return or fill in a AL_FS_ENTRY struct (but 
not open it), but I wasn't sure how people would react to that so I kept with 
a simpler stdio like function.

> --
> Matthew Leverton
>
> ---------------------------------------------------------------------------
>---


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx