usage with multiple archives with similar directory structure and API feature suggestion

Robby Dermody robbyd at
Wed Jul 17 20:20:19 EDT 2002


I'm going to be using both the C++ physfs wrapper and physfs's C api in the
same project, since I"m using paraGUI in one component and I figure I'd be
easiest to use the same base library in the other component (the project has
both C and C++ components, some of the C code being shared code...I got it
sorted out so the library is only initialized once, but I
digress)...basically the structure of my resource files is like such (the
proposed view for each archive):

    info.xml - XML descriptor file for the data entries
    01 - category 1
        01 - sub category 1
            01 - entry 1
        02 - sub category 2
            01 - entry 1
    02 - category 2
        01 - sub category 1
            01 - entry 1

and so on....this structure is reproduced in about 8 different resource
files. Normally this isn't a problem, however it becomes a big problem when
I use physfs, since it takes the filename abstraction I depend on to
differentiate the data out of the equation. I'm wondering if there's any way
around this without having to change this directory structure. If not, the
simplest think I think I can do is to enclose the contents of each resource
file in a different directory, for example:


I want to know if you guys think this move is necessary.


Also, right now I'm getting physfs to work with my resource file I/O, but I
plan on using physfs for file access from within scripts. I would like to
have two separate configurations for this, which I can switch at well. It
seems that the physfs library only allows one instance (no passing of a
state object around) and one active configuration...I don't see this
mentioned in TODO so I figured I'd put it out in the open and see what
people think about it...

The easiest way I see of doing this, given physfs's current API is to have
something like PHYSFS_switchActiveConfig() and PHYSFS_getActiveConfig()
functions.... by default active config 0, or whatever, will be used without
having to call this (which will ensure backwards compatibility), but when
the function is called, you are switched to another active configuration and
you can define a different search path, etc. at will. This would be useful
because you could have one configuration for when you read/write your main
data files, and a different one for scripts that want to access your files.
The configurations would be on a per-thread basis to ensure thread-safety.
Now this could be done outside of physfs, with functions that clear the
search/write/base paths and establish different defaults, but I think it
would be cool if done within the library itself...including faster.



More information about the physfs mailing list