William A. Rowe, Jr. wrote:
Wondering if this is worth a great deal of time until we define the VFS
in less APR'ish, less filesystem'ish patterns.
Maybe an APR-like file-system interface is an appropriate interface for
a virtual filesystem? I guess it is a question of how much you want to
try to achieve in a VFS...
A VFS interface would need to be quite similar to the FS interface in
APR (perhaps a superset)? if you wanted to be able to virtualize all
resulting request related file IO you are going to need to be able to
fill in operations for all of the FS equivalents to apr_file_(stat,
open, read, write, close, lock, unlock, remove, perms_set, ...),
apr_dir_(open, read, close, make, remove), etc. The VFS should have
complete coverage to allow intercepting of all request related file (or
resource if you like to call it) IO otherwise it would not be quite so
useful.
There are other existing httpd VFS abstractions such as DAV resource
providers which already offers a high level non-file centric VFS
interface although this can't be used across encapsulation boundaries
such as in apr-util and is perhaps a bit heavyweight for more pervasive
usage internally (and doesn't support enough low-level operations to
support things such as mmap and sendfile)?
Without a low-level APR VFS interface, how would we cross encapsulation
boundaries such as brigades and dbm in apr-util? I think a VFS should be
able to virtualize all file IO including that from any other modules
that use APR file IO interfaces (at least that is what I need personally
:) ). It also needs to (optionally) handle sendfile and mmap which are
low-level concerns (e.g. a memory file cache VFS provider could handle
zero-copy IO by filing out a sendfile or mmap implementation).
My VFS delving has always led me towards the creation of a generic (and
rather pragmatic) way of getting request_rec* passed down to an APR
interfaced VFS provider with the addition of a generic apr_vfs_context*
argument (a container for request_rec* in httpd) to APR file IO
interfaces with transitional support for the present APR file IO
interfaces (without explicit vfs_context* argument) by the use of a
thread local variable - this could be made more robust by converting
apr-util to use new interfaces and explicitly pass this vfs_context*
(but it could be done quite robustly in the meantime by pushing and
popping of contexts during starting and end of requests and their nested
sub requests - or in an event driven mpm, changing contexts when required).
Here is the URL to my notes again for those interested:
http://privsep.org/AprVirtualFileSystem
Perhaps you could s/file/resource/, s/dir/collection/, s/filename/uri/
but that still leaves the problem of the code that crosses encapsulation
boundaries in apr-util (my reasoning for needing an interface in APR).
BTW - FUSE on Linux also has the same fuse_context* pattern for getting
context specific information down to filesystem providers:
http://fuse.sourceforge.net/doxygen/annotated.html
Just another random thought - A low-level VFS interface may make it
possible to have a mod_vfs_fuse allowing you to run fuse filesystems in
apache.
With a robust VFS for httpd, your provider could register the
corresponding
content for a request, and negotiation would query VFS providers of both
multiview matches, type-maps, and your i18n.
The queries would end up as stat calls to a low-level (V)FS provider
somewhere.
I guess from an APR centric view of a VFS (how I've been thinking about
it) you could hook stat and open (and read/write for your translation
substituted file) to do this although I'm not sure if it would be the
best way - possibly it would be for the read/write to the language
substituted (virtual) file (which you might layer hypothetical generic
VFS caching on top of if your generation was expensive) but the query
support might need to be at a higher level. A VFS provider that didn't
serve the same file for the same path at this layer would need to change
the request appropriately for negotiated content (as it would break
existing assumptions).
Should this be within the scope of a VFS or do you think this might be a
higher level requirement? Could mod_include be taught to substitute
language specific strings from a YAML translation file?
my 2c.
Michael.
