dvfs api and toolkits

[Sean Middleditch]

On Mon, 2005-04-04 at 23:48 +0100, Jamie McCracken wrote:
> Sean Middleditch wrote:
> > 
> > In fact, it should be no less efficient than the basic wrapper around
> > the IPC mechanism itself, which is something you absolutely must have no
> > matter what in order to ensure correct processing of the protocol.
> > 
> 
> That would depend on whether the wrapper allowed direct access to the 
> backend (ie in process usage). Obviously to do this you would need to be 
> able to query the backend (is it A or C and whether it needs the daemon 
> for connection/password) - being able to bypass the daemon if its not 
> required is certainly possible but I dont know whether you plan to allow 
> for that on the client side. I do feel its necessary as there's bound to 
> be performance critical apps that would want this and if thats the case 
> they can do their own threading if necessary.
> 
> I also feel more direct access to the drivers would provide more 
> primitive posix style operations (read/write x bytes) and thus provide 

Not happening, already discussed, the daemon and only the daemon will be
used, with no exceptions.

> more flexibility then the high level document interface which might not 
> be appropriate for some things (EG log files where you want to append 
> text without reading the whole file into memory, mime type sniffing 

Don't use D-VFS for log files.  D-VFS isn't for log files.  It's not for
configuration files.  It's not for application data files (ie, stuff
in /usr).  It's for documents.  Maybe we should call it Document-VFS
instead of Desktop-VFS.  ;-)  Config files, log files, and so on can and
should be accessed using plain POSIX.  D-VFS won't give you much for
reading static data out of /usr, appending lines of text to a file
in /var, or reading simple text files located in $HOME (or, preferably,
using a better configuration API).  D-VFS is for user documents that the
user directly manipulates that may be stored in many places besides
locally mounted/accessible paths.

> using the first 100 bytes of a file etc)
> 
> 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.
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.

Any possible latency caused by the IPC/daemon is going to pale in
comparison to the latency over the network to the remote hosts.  Even
when accessing local files, no application should be doing constant
uninterrupted file access with D-VFS.  Load your document, save it
again.  If you're doing anythign much more complex than that, you
shouldn't use D-VFS, you should tell users to mount an NFS share or
something and use pure POSIX.

> 
> jamie.
> 
> 
> 
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>