Re: [AD] Splitting filesystem APIs

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

Thomas Fjellstrom wrote:
> It is becoming clear that I have less than no say in what happens to the lib 
> though. (I suppose thats fine, I've really only contributed this code, the old 
> alsa 0.9/1.x driver, and a small fix for xinerama support in a5). It has made 
> me think about evaluating how I spend my time. I'm not sure this has been 
> entirely worth it.

There really was nothing to gain from it all along - it's just an open source 
project, and a very low profile one at that. If it's not fun for you working on 
it just for, well, fun, you really shouldn't.

In any case, it's unfair to say that things are now changed without a good 
reason. If you look at the posts here from the last few days, you'll find that 
quite a few issues with the fs code in current SVN were mentioned:

- Search paths (some find them not easy to work with)
- Current directory (I don't quite understand the issue myself, but still..)
- ALLEGRO_FS_HANDLE can be a file or directory (some don't like that)
- ALLEGRO_FS_HANDLE can be an opened or not opened file which is confusing
- thread-safety (is a MUST and not up to discussion as far as I'm concerned)
- how do you open files within a zip archive (and code physfs addon to test..)
- how to use non-stdio filesystems in general

So, if we want to get A5 out this year, these issues all need to be fixed. And I 
expect Peter's upcoming commit to fix most of them (except the directory 
handling which he said he would leave to someone else).

He also already said that it won't be a big change from how things currently 
work - the biggest change likely is the ALLEGRO_FILE type - which should be an 
obvious change if you look at the list above. (I wouldn't totally rule out that 
we keep ALLEGRO_FS_HANDLE after all, especially if someone can come up with an 
example where it is much easier to work it - but right now I'm also seeing more 
arguments against than for it.)

--
Elias Pschernig <elias@xxxxxxxxxx>