dvfs api and toolkits

[Sean Middleditch]

On Tue, 2005-04-05 at 01:37 +0100, Jamie McCracken wrote:
> >>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.

I suspect that the number of backends that will work flawlessly without
the daemon will be very limited.

I originally agreed with you on this - look at my original proposals
posted to the list.  Also look at the responses, to see why I was
convinced to go with a daemon-only approach.  There is no reason to
re-discuss this.

> 
> > 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.

It shouldn't have to.  That's half the point of D-VFS - no need to work
around stupid APIs.  If we tell application authors that they get
correct asynchronous behavior with some protocols and need to do all the
complex hacks that POSIX required of them for other protocols,
developers will just tell D-VFS to bite it.

D-VFS is capable of making local file access work like all other
protocols, and so it shall.  :)

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

No such thing as one size fits all.  POSIX works great for some use
cases and poorly for others.  Same for D-VFS.  Anything POSIX *can* do,
D-VFS should be able to do, but there will be cases when POSIX is just
the better fit.

> 
> 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.

These are old points, already discussed, already taken into
consideration, no reason to repeat all this.  Read the archives and the
wiki page.
-- 
Sean Middleditch <elanthis at awesomeplay.com>