-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flesh out plans for ResourceManager #265
Comments
Thanks for writing up your thoughts. Two questions: When you say: The folder Does this mean you can somehow rename the mounted directory? Would this be an override to the constructor that allows specifying the real directory mounted and the new name? If we implement multiple mount points, what takes priority? I think the answer is the most recently mounted directory working backwards to the original mount used in the constructor. This would best mimic how Outpost 2 does it when we invoke it with the ConsoleModLoader. Thanks, |
Yes, the names in the virtual filesystem don't need to correspond to names on disk, making it possible to rename things. Keep in mind, the example was for the general case with non-root mount points. I don't propose implementing that at this time. Rather, I'd like to stick with a design that allows that to be implemented in the future. Modifying the above example so it mounts the real folder This is the simple case, which is sufficient to support working with Outpost 2. An additional example. We could also mount Priority is based on order in which the mount points are added to the virtual filesystem. The virtual filesystem would scan it's list of sources, in order, and find the first matching name, or return an error if none was found. We may want to provide methods to insert new sources in a particular position. PhysFS has such a mechanism. An example is methods to add first ( |
Another side idea, we could have a filtered folder tree which gets mounted. Maybe you only want access to files of a specific type. Example (with non-root mount points): class FilteredSubTree {
FilteredSubTree(const std::string& basePath, const std::string& fileGlob);
};
class VirtualFilesystem {
Mount(SubTree& subTree, const std::string& mountPoint);
};
virtualFilesystem.Mount(FilteredSubTree("data/", "*.bmp"), "images/");
virtualFilesystem.Mount(FilteredSubTree("data/", "*.map"), "maps/"); In the above, the real filesystem might mix |
First up, I think
ResourceManager
needs to be rename. As per the Clean Code Collection, "Manager" is a suspect name. Considering what the class does, perhapsVirtualFilesystem
might be a better name. The class's responsibilities are similar in some ways to what the PhysFS library does, which is basically a virtual filesystem, so some inspiration may come from there.A virtual filesystem could support mounting of various sources into an integrated view. That may include archives, such as VOL and CLM, or a subtree from the real filesystem. The result would appear as if it was a single folder subtree. Mount points appear as folders in the virtual filesystem.
Example view of
VirtualFilesystem
folder tree:Side note: Outpost 2 does not have non-root mount points. Hence why I've marked that part as optional. Still, it may be worthwhile to consider the more general case.
Mount points should be allowed to overlap, with identically named files hiding others of lower priority. It is not an error if two files mounted from different sources end up at the same virtual path. Only one will be visible. That would be consistent with how Outpost 2 handles accessing files from VOL archives. All archives are mounted to the root of the virtual filesystem. During search it returns the first file it finds when searching all archives. In Outpost 2, the folder tree representing the filesystem has the highest priority, with VOL files coming next, depending on the order in which they were loaded.
Example:
In priority order, a real filesystem subtree, archive1.vol, archive2.vol, are all mounted to root.
Contents of filsystem subtree:
Contents of archive1.vol:
Contents of archive2.vol:
This would result in the following virtual filesystem view:
Access to resources is done using relative filenames, which are relative from the root of the virtual filesystem. If the file corresponds to a real disk file, the real filesystem path can be obtained by stripping the virtual mount path and then prepending the real filesystem path of the subtree mount point.
Example:
The real filesystem contains a file:
resources/data/image.bmp
.The folder
resources/data/
is mounted into the virtual filesystem asimageData/
.Access to the file is through
imageData/image.bmp
.To convert to a real filesystem path, first strip the mount point
imageData/
:imageData/image.bmp
->image.bmp
Then prepend the real filesystem path of the mounted subtree
resources/data/
:image.bmp
->resources/data/image.bmp
Related: Issue #232.
Responsibilities of
VirtualFilesystem
are being able to view, search, and open streams to the contained files, using a single unified virtual filesystem path. This corresponds quite well with the current methods offered byResourceManager
, which are able to search paths and open streams.In terms of future direction, we can rename the class, generalize how files are mapped in from the mount sources (perhaps defining a
FolderSubtree
interface), perhaps expand methods to support viewing of the virtual filesystem, and at some point down the road, if we feel like it, or want to reuse the class in another project, we could add non-root mount points. That last part is not a priority.The text was updated successfully, but these errors were encountered: