[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: continued: Common-VFS proposal
From:       Waldo Bastian <bastian () kde ! org>
Date:       2005-01-26 14:47:41
Message-ID: 200501261547.45977.bastian () kde ! org
[Download RAW message or body]


On Wednesday 26 January 2005 00:17, Richard Moore wrote:
> I totally agree with Havoc here. I would add that it important to have
> both a 'transparent' (everything can be treated as local) and an
> 'i-know-this-is-damn-slow' api in any general purpose abstraction like
> this. There will always be applications where a streaming API is
> needed (such as progressive rendering) and even worse, both APIs may
> be needed by the same app.
>
> Rich.

Indeed.

I think the paper below does a good job explaining the problems with taking 
transparency too far. You can and should go to great length to make remote 
access as easy as possible and as similar as possible to local access, but at 
the same time you will need to realize that local and remote access have 
fundamental different properties and that your design needs to take such 
differences into account. A POSIX style API fails to do that.

http://www.sunlabs.com/technical-reports/1994/abstract-29.html

I think the approach that we have taken in KDE with KIO works very good, 
especially if you take the KIO::NetAccess classes into account that provide a 
synchronous interface for applications.

For a common VFS solution I would start with that, clean up the protocol, add 
better documentation and make some adjustments as seemed fit.

Cheers,
Waldo
-- 
bastian@kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian@suse.com  |   http://www.novell.com/products/desktop/eval.html

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]