continued: Common-VFS proposal

[Waldo Bastian]

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 at kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian at suse.com  |   http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050126/42c7b39c/attachment.sig>
-------------- next part --------------
_______________________________________________
xdg mailing list
xdg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg