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:
pgp0JY4gUaCcq.pgp
Description: PGP signature