whefs  whefs-TODOs

whefs TODO

This is my personal list of "immediate" TODOs (in no particular order):

  • Several parts of the public API need to be rounded out.
  • 20090609: Add a public interface for iterating over inodes, maybe similar to opendir()/readdir().
  • Once the API settles down i'll provide an OO wrapper API for C++. Adding a stream wrapper for std::i/ostream shouldn't be difficult, either.
  • Directories. See ticket [10857664fa] for my current thoughts on that.
  • Concurrency via advisory locks (POSIX fcntl()). See ConcurrencyInWHEFS.
  • Concurrency via threads. See ConcurrencyInWHEFS.
  • Scripting language bindings via SWIG. i've tinkered with scripting the i/o layer a bit, and i don't think making whio/whefs play nicely with SWIG will be all that difficult to do. We've already got hand-implemented JavaScript bindings for whefs.
  • Add storage for Unix access rights on the inodes (not user/group IDs), or at least +x bit. We have no intention of using them to control access within the VFS, but for when we export the data to a file (so we can keep the original permissions intact).
  • Add client-supplied metadata to inodes, in the form of (for example) 2 64-bit numeric slots. These could be used to store client-specific stuff like user/group IDs, file type information, and such.
  • Add ability to "mount" a VFS as a subdirectory of another VFS. This has a big fat can of worms attached to it, though, and is dependent on directory support (which is in turn dependent on path parsing).
  • 20080111: (maybe) change file format to put block metadata all together and block data all together. This will simplify certain operations. The format originally kept them together (on disk) because it made it easy to visually check if the layout was doing what it was supposed to (i used 'less' as a test tool before i got pseudofiles working).