httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Clark <>
Subject Re: VFS Proof of concept
Date Mon, 24 Dec 2007 11:54:13 GMT
Nick Kew wrote:
> In lieu of giving you that round tuit just now, can I just check
> whether you're familiar with APVFS[1]?  It looks as if you're
> treading out similar ground here.
> [1] or

Yes it does. Thanks very much for the pointer. This is very close.

A few points:

* Its VFS API is an 'exact' mirror of the apr API while in the use case
I am looking at we would need to be able to pass down request_rec*
context from within httpd so that a VFS module implemented within httpd
could have behavior based on the vhost or request. i.e. We would need
some sort of application specific *context arg on the _vfs versions of
the file IO API (although it could be omitted on file_read, file_write,
file_close, dir_read, dir_close, ... as they can store context in their
vfs_file_t or vfs_dir_t during file_open, dir_open).

* The VFS provider API should have an additional argument to all of the
provider implementation calls (in this case apv_vfs_t*) in addition to
passing through the *context mentioned above - this is so that it could
more easily support stacking and multiple mount points (multiple
instances of a particular VFS provider) - as at present their arg also
exactly match that of APR and there is no instance specific context
(they appear to be global).

* Instead of scheme:/ it might be nicer to be able to mount these VFS
providers somewhere within a regular file namespace. This would allow
compatibility with existing code and would be needed for stacking.
stacked VFS providers could then use their per instance data to pass
through to an underlying VFS implementation e.g. a VFS provider that
just does logging, or performance statistics, etc (I've been looking at
Samba 3 as their VFS support these aspect-oriented stacked VFS providers).

View raw message