[Scummvm-devel] File handling revamp

Marcus Comstedt marcus at mc.pp.se
Tue Jul 29 14:09:00 CEST 2008


Max Horn <max at quendi.de> writes:

> -> Solution: Make it possible to provide alternate File-class
> implementations, just like for FSNodes. One way would be by adding a
> FileManager class, with internal methods like
>   SeekableReadStream *openFileForReading(String name);
>   SeekableReadStream *openFileForReading(FSNode);
>   WriteStream *openFileForWriting(String name);
> and then the File class simply calls these in open(), and otherwise
> calls-through to the stream object it obtained.

Wouldn't it be simpler to just have

  SeekableReadStream *openFileForReading();
  WriteStream *openFileForWriting();

in the FSNode class?  Since FSNodes can already be provided by the
backend, the FSNode can return port-specific file objects.


> * The more I think about it, the more I like the idea of having a
> pure virtual FileManager class (to be implemented by ports, with a
> default implementation based on FILE), which provides some
> minimalistic core API for creating File/DumpFile/ConfigFile/SaveFile
> streams. The point being that a port could use the exact same
> implementation for all these types of files, or use a completely
> custom one for each.

If the implementation is different for each one, then it becomes even
more clear that this needs to be integrated with ths fs code, not
separate from it.  I mean, if File, ConfigFile and SaveFile have
completely different implementations, they will more likely than not
have different namespaces for their filenames as well (this is
definitiely the case with game files and savefiles on the Dreamcast).
So if you create a FSNode("foo"), and do ->exists() in it, should it
check whether there exists a "foo" in the namespace of Files, in the
namespace of ConfigFiles, or the namespace of SaveFiles?

In short, the FilesystemFactory needs to be in on the whole deal.


Btw, if we are going to redo the fs, I'd again like to propose having
different calls for creating a file node and a directory node, rather
than having a common node that you can ask if it is a directory.
I think it would result in simpler, more robust code (both for
implementers and for users).  The only downside is that getChildren
would have to fill two lists (one with files and one with
directories), but I figure that in the places you use it, you'd
typically want to separate the directories from the files anyway
(e.g. file browsers usually like to display all subdirectories
first).


  // Marcus






More information about the Scummvm-devel mailing list