dvfs api and toolkits
jamiemcc at blueyonder.co.uk
Tue Apr 5 03:37:06 EEST 2005
>>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
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
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.
More information about the xdg