[Scummvm-devel] ENGINE AUTHORS: case-insensitivy and directory handling

[peres]

Hi team

I am posting a proposal to solve the issue about case-sensitiveness and
directory handling in the engines. I will do a quick overview first.

ScummVM provides Common::File to access files in the game directory, but
requires switching to the completely different - and lower level -
FilesystemNode API whenever access to data stored in subdirectories is
needed, with the difference that while Common::File is guaranteed to be
case-insensitive, FilesystemNode can't.
So there is one practical issue (the case mismatches) and one
philosophical issue (the existence of two independent API's to access game
data).

Case mismatch - from the engine point of view - has an optimal solution in
turning FilesystemNode case-insensitive. This optimality would be two-fold:
because games can be safely considered to have non-ambiguous file names
(case-wise), and because the implementational burden is moved to the
backends.
The missing piece of the picture is that we could decide to use the low
level FilesystemNode to deal with other stuff besides game files (config
files, themes...), and since the final user may be involved in these
processes, we shouldn't trim his/her ability to exploit the
case-sensitivity feature of his/her file system.
Moreover, changing FilesystemNode doesn't solve the second issue - the
philosophical one - as both API would continue to co-exist, though with a
possibly tighter integration (like only allowing Common::File to be opened
on a FilesystemNode).

The recent discussion on the devel mailing list has brought the idea of
unifying the handling of game files and directories in a single API that
sits atop of FilesystemNode and deals with case-sensitivity issues for the
engines. This API would thus replace Common::File in the medium-long term,
also providing a way to access files in subdirectories.

The concept is to model directories instead of a game file, and give the
engine an instance of the directory where the game is stored. This could
be asked to open a file, for which it would return a readable stream, or a
directory, for which it would return another directory object.

Going a bit further, this approach also allows more powerful and flexible
file searches than the current default directory system - implemented as
static members of Common::File - does. The key is an object that manages a
set of the directories introduced above, together with an array of
settings that specify how searches should be performed (per directory!),
for example how deep a certain directory can be searched, if hidden files
should be considered, and so on...

The attachment contains a quick implementation of both classes I sketched
in this mail: I called them GameDirectory and GameDirectories. It should
be considered a proof of concept more than an usable piece of code, and
has shortcomings so far (like what to do with FSList returned by
matchPattern). Anyway, I would be glad if engine authors would drop their
considerations about it. I am also posting on the patch tracker so the
code is easily reachable in the future.

A final word on the way this can be applied to the code base, provided
there is a consensus around it. Moving engines from Common::File to
*anything* different is indeed a massive task (there 134 engine files
referencing Common::File as of today!), but the process can be carried on
gradually, by having this API in parallel and changing code in steps.

bye
Nicola