A common VFS and a Common conf-system [Part II]

[nbs_r at gazeta.pl]

While I fully agree with load/store D-VFS semantics, a POSIX-compliant 
fall-back for _local_ document copies could be very useful. What I mean, 
is we should not restrict operations that can be done with already 
downloaded documents. If an application wants to "mmap" or "seek" the 
local document copy by itself D-VFS should not interfere with this. What 
I humbly propose is:

   1. "Load" checks a document out of the D-VFS backend. If necessary 
(i.e. the backend is not a "file://" protocol) the document is copied to 
a local directory(*1). The file may (but does not have to) be 
automatically mmaped to the shared memory if the application requests 
that. Otherwise, the path of the local copy is made available to the 
application.
   2. The application may open the local copy and use any POSIX 
operations on it. The D-VFS specification should not introduce any 
constraints other than reflecting the access rights of the remote copy 
in the attributes of the local one.
   3. "Store" closes the local file and checks the document in the D-VFS 
backend. Assuming we do not provide caching ability the local file can 
be deleted. However if an architecture with a daemon is to be used 
documents caching implementation can be quite easy and reliable.
   Why using local copy/reference:
- This method provides a robust and efficient fall-back for "file://" 
backend.
- Porting applications that strongly depend on POSIX API will be easier.
- It is necessary for document caching.
- POSIX API can be used _only_ for local copies, therefore it does not 
clutter the (remote) D-VFS semantics.

*1) A bidirectional path<->URI mapping convention will be necessary.

A fall-back utility for D-VFS-unaware programs:
Combining the above concept with a wrapper utility we can enable 
POSIX-only applications to benefit from D-VFS. There are two 
possibilities that comes to my mind:
   1. Explicit file download. The sample wrapper command invocation 
could be like this:
$ dvfswrap [-R] [URI_cache_pattern] URI program [program_args] {}
("{}" is a "find"-like substitution pattern). The "-R" option and 
URI_cache_pattern explicitly provide dependent files for the "program".
   2. On-demand file download. The wrapper could intercept open/close 
function calls and download all the necessary files. In this case a user 
does not have to specify the dependent files so the command invocation 
could look like:
$ dvfswrap URI program [program_args] {}
   In both cases the wrapper utility should intercept termination of the 
program and "store" the changed document(s) if necessary. As command 
line programs often run from scripts, they will particularly benefit 
from document caching.
   While this is an optional functionality, (IMHO) it would be useful to 
provide a coherent way to wrap the POSIX-only programs.

What is unrelated to the above but still quite important (and I did not 
find it in the wiki) is a possibility to query the D-VFS backend about 
the implemented interfaces/operations. Obvious choices for such 
interfaces are:
- CD/DVD burn/erase interface,
- Check-in/check-out/diff/... for revision control systems,
- Backend options/logs, etc.
As hardcoding all the possible operations is impossible, a D-VFS backend 
should advertise non-standard interfaces to the client application. Then 
the application can simply add backend-specific GUI controls to the 
menu/panel. I am not sure if it needs to be specially addressed in the 
D-VFS specification or D-BUS will make it for free.

Regards,
Andrzej