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] http://apvfs.sourceforge.net or > http://sourceforge.net/projects/apvfs >
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).
