W3C home > Mailing lists > Public > uri@w3.org > August 2002

Re[2]: URI "functions" and the Gnome VFS

From: Al Gilman <asgilman@iamdigex.net>
Date: Fri, 16 Aug 2002 15:31:54 -0400
Message-Id: <5.1.0.14.2.20020816150856.0213baf0@pop.iamdigex.net>
To: ettore@ximian.com
Cc: uri@w3.org, Norman Walsh <Norman.Walsh@Sun.COM>, JP Schnapper-Casteras <jp_sc@yahoo.com>

At 12:56 PM 2002-08-16, Dan Connolly wrote:

>Hi,
>
>The gnome VFS stuff looks nifty; but the use
>of '#' to compose functions with URIs looks
>backwards to me...
>
>[[
>  Unlike normal Internet URIs, though, GNOME VFS allows stacking of
>access methods. For example, assume you want to read a file which is
>stored in a .tar file. In that case, you want to be able to open the
>parent .tar file, extract the file you want, and read it. In practice,
>you need a tar file access method that is able to extract a file from a
>.tar file, and you also need an access method to access the .tar file
>itself.
>
>This means that you want to stack the tar access method "on top" of
>another generic access method to read the .tar file itself.

I would have thought that a _virtual_ file system would hide the unTar
application.

And that the VFS implementation of a file: URL would be ambiguous as to
where the unTar took place anyway.  The file path would drill right through
the level at which the directory was encoded for archiving without noticing,
and the remote archive server would either unTar to return the level addressed
in the file: URI or return a tuple of a tar archive of a directory
corresponding to an initial substring of the file: path and the residual path
that still had to be traversed after the recipient unTarred the archive.

Check out the various threads of work visible in the remote file access
activity in the Global Grid Forum,  Closest to Gnome is probably the work of
Micah Beck at Tennessee.

  Micah Beck
  http://www.cs.utk.edu/~mbeck/

  Global Grid Forum Remote Data Access Working Group
  http://www.zib.de/ggf/data/

Al
Received on Friday, 16 August 2002 15:32:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:04 UTC