dvfs api and toolkits

[Jamie McCracken]

>>It could be that you have two objects on the client side - one for low 
>>level access sans daemon and the other for providing a high level 
>>document interface which always utilises the daemon.
> 
> 
> Except that putting it in the client makes it impossible to work
> correctly.  You lose session sharing, password security, and so on.

Ah but thats why we need to ask the backend whether it needs the daemon 
or not. Of course for a file uri its obvious but others will just need 
to query and its trivial to implement.

> Putting it in the client also destroys the possibility for the API to
> actually be synchronous for things like local file access thanks to
> POSIX suckage, and local file access is the only place I'd imagine you
> could even begin to notice a performance hit from D-VFS.  If you are
> doing local file access and need the best hand-tweaked performance, use
> POSIX.

Accessing a file uri in that way should not be a problem as the POSIX 
backend would be synchronous anyhow - the client app can do any 
threading itself if needed.

I was hoping D-VFS would be a replacement for POSIX for most 
circumstances but limiting it severely restricts whats gonna use it.

The problem is file managers like nautilus need low level access for 
efficient implementation of Mime sniffing, custom metadata extraction 
(eg MP3 files) , creating links and folders, getting/setting permissions 
etc. Whilst I admit the high level stuff is great for things like the 
file chooser and document based apps I however cant see nautilus making 
use of it if its strictly limited to "documents" and document related 
functions.

I respect the fact you want to keep it KISS but having dual access (low 
and high level) via separate objects should not complicate things and 
make it more likely to be accepted across the board.

jamie.