Saw comment about virtual file system on web page. Padding hack might work well enough. Alternate approach is to view file system implementation as an API implementation to be called by OS (or other host of file system). I.e. to implement a file system view of some resource, you are essentially writing a shim that talks to the OS/host on the one side and the resource on the other. You must, of course, analyze the two sides to see if the twain shall meet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the main problem here is the ebookman OS does not support folders and subfolders. All files share a 'flat space'.
While this might be implemented in the future, we just can't rely on it so we'll have to make up our own thing.
tar gnuzip .tgz tarballs were first discusssed as an option (single file, which makes it easy to pass along, but still containing a folder and files tree). However this format does not allow for expansion of individual files, so it kind of defeats the purpose of having compression (if you have to expang the tarball in memory, you need spce for the archive _and_ expanded data :)
last posts I saw about this were about using ZIP instead, which allows for files and folders, is standard enough to be used on all platforms, and provides the ability to uncompress a single file from the archive.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Saw comment about virtual file system on web page. Padding hack might work well enough. Alternate approach is to view file system implementation as an API implementation to be called by OS (or other host of file system). I.e. to implement a file system view of some resource, you are essentially writing a shim that talks to the OS/host on the one side and the resource on the other. You must, of course, analyze the two sides to see if the twain shall meet.
the main problem here is the ebookman OS does not support folders and subfolders. All files share a 'flat space'.
While this might be implemented in the future, we just can't rely on it so we'll have to make up our own thing.
tar gnuzip .tgz tarballs were first discusssed as an option (single file, which makes it easy to pass along, but still containing a folder and files tree). However this format does not allow for expansion of individual files, so it kind of defeats the purpose of having compression (if you have to expang the tarball in memory, you need spce for the archive _and_ expanded data :)
last posts I saw about this were about using ZIP instead, which allows for files and folders, is standard enough to be used on all platforms, and provides the ability to uncompress a single file from the archive.