[Scummvm-devel] File API

[Marcus Comstedt]

Max Horn <max at quendi.de> writes:

> Right now our file code is split in three blocks: class File; then,
> SaveFile & SaveFileManager; finally, FilesystemNode & FSList. I'd like
> to see this cleaned up and unified.  I am not yet fully sure how the
> result could look, but the design would be driven by our needs, of
> course. So I try to list them here.
>
[...]
>
> * One idea for a new design might be to have a (singleton)
> * FileManager, which is used to create File objects (of one of the
> * tree types listed above). That class would also deal with the other
> * points listed above (browsing, existence check, searching multiple
> * dirs for files, etc.). The implementation of it would be left to
> * porters. We'd provide a default implementation, but porters could
> * provide their own. Not yet sure how that would look exactly,
> * though. Maybe part of the system would be in common/file.h (the
> * portable parts), and another part would reside in backends/file (or
> * backends/fs like now).

Sounds good to me.  This would allow the posix-fs to be reused for
game data, while at the same time providing a completely different
(but interface-compatible) filesystem implementation for save-data,
something which is not currently possible.  You could even do tricks
like overlay filesystems by instantiating multiple posix-fs:es.


> * We need to browse the filesystem / contents of a directory:
>    1) For listing savegames - this is essentially what SaveFileManager
>    does right now

The savegame listing might require some additional thought.  Right
now, a single directory is used on UNIX for storing savegames, and on
the Dreamcast a kind of virtual directory is used which is actually
the union of the directories on all the memory cards.  Maybe some
subdirectory scheme could be employed here to provide the user with
finer control over where to save the savegames, like which memory card
to save on.  Or maybe this would just complicate the GUI, I dunno...


Btw, some mechanism to communicate error messages from the filesystem
layer to the engine would be nice too, e.g. when a save fails the
engine can get a string back to show to the user somehow.


  // Marcus