--nextPart3924728.vhs8mBJiHM
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=
=20
transparency too far. You can and should go to great length to make remote=
=20
access as easy as possible and as similar as possible to local access, but =
at=20
the same time you will need to realize that local and remote access have=20
fundamental different properties and that your design needs to take such=20
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,=20
especially if you take the KIO::NetAccess classes into account that provide=
 a=20
synchronous interface for applications.

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

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

--nextPart3924728.vhs8mBJiHM
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQBB962RN4pvrENfboIRAp0WAJ4rgMEwzsl9bY088ESb4cZKlOXIyACcCqaV
49G2QapZtNwH4NVAOR5p9k0=
=tDuD
-----END PGP SIGNATURE-----

--nextPart3924728.vhs8mBJiHM--