[Scummvm-devel] Progress with Archive & SearchManager
Max Horn
max at quendi.de
Sat Sep 27 17:56:56 CEST 2008
Hi folks,
it would be really nice to finally get the whole Archive &
SearchManager business completed, so that we can start definite bug &
regression hunting and convert all ports to the new system. There are
two open tracker items, with pending patches, but overall, I would
like to discuss where we are, where we want to go and what we need for
that.
We successfully reached most of the goals outlined in the "File
handling revamp" thread. The following list is taken from my local
TODO file:
* Split off DumpFile from File
-> DONE
* add Buffered(Seekable)ReadStream
-> DONE
* add config file load/save API to OSystem
-> DONE
* make FSNode case insensitive ??
-> REJECTED
* add openForReading()/openForWriting() methods to FSNode
-> DONE
* change File::open to use those method
-> DONE
* add POSIX path parser for use in File::open
-> pending, probably REJECTED as we will phase out File completely
* change Stream ioFailed() semantics to match POSIX ferror
-> DONE
* SearchDirectory ("SearchPath"?) class which caches all files in a
dir (and its subdirs?)
-> in progress
* add docs to class File
-> in progress
Some extra stuff cropped up in the meantime:
* convert .ZIP access code to the new Archive API
-> DONE
* convert .ARJ access code to the new Archive API
-> pending, help welcome!
* convert ScummFile class(es) to new Archive API
-> pending, help welcome!
One of the pending patches is about adding a new ArchiveMember class,
which are primarily meant to simplify things in Kyra, if I recall it
right. Look at patch #2034983 for details. I think this patch by peres
is mostly ready to be checked in; although I must admit I do have some
doubts whether this is the best way to go (by introducing the
ArchiveMember class, we add another indirection layer, which on the
one hand may simplify some client code, but on the other hand makes it
quite a bit harder to implement an Archive subclass; and I am not yet
sure whether this is a good tradeoff. But I think it's fine to keep
working a bit longer on this particular patch.
The main missing piece, in my eyes, is finishing the SearchManager.
This is a singleton which is meant to manager the "search paths" of
ScummVM; think of it as the successor to the
File::addDefaultDirectory() API. The quicker we get this finished, the
sooner engines can be converted to the new APIs.
The first step to this would be to initialize SearchMan properly, in
base/main.cpp and elsewhere; look at Patch #2093502 for some work on
that, and various comments for what one has to watch out. A good start
for this might be to convert class File to use SearchMan instead of
its own s_searchSet. But there is a catch: namely when/where to call
OSystem::addSysArchivesToSearchSet. Maybe we need to add a reset()
method to SearchMan, and then let that method invoke
OSystem::addSysArchivesToSearchSet.
By following this approach, it gets easier to migrate Engines
*gradually* away from the File::addDefaultDirectory() API. This would
be the next step. First, convert File::addDefaultDirectory calls. Then
replace anything which does "new File" to use SearchMan::openFile
instead. Finally, consider replacing all uses of File (but let's not
rush that). Oh yeah, one thing we must watch out here is that class
File has a hack which makes it identify the filenames "FOO" and
"FOO."; this is, AFAICT, for Simon's GAMEPC file only, so my hope is
that we can push this hack to the AGOS engine.
In parallel, other code should be converted away. For example, the GUI
code, the MT-32 emulator, anything which uses class File in some way.
By properly using the Archive class, there is even some potential to
considerably simplify some code which right now tries to open stuff
both via File::open and ZIPArchive -- this can be merged into a single
call by using our fancy new "SearchSet" class (see common/archive.h).
Cheers,
Max
P.S.: originally I meant to send this mail to LordHoto and peres
alone, but I figured it wouldn't hurt to send it to the public, in
cases others want to chime in -- as highly unlikely as it is :)
More information about the Scummvm-devel
mailing list