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

Re: URI "functions" and the Gnome VFS

From: Al Gilman <asgilman@iamdigex.net>
Date: Fri, 16 Aug 2002 13:51:16 -0400
Message-Id: <5.1.0.14.2.20020816132703.0219cd20@pop.iamdigex.net>
To: Dan Connolly <connolly@w3.org>, 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.
>
>Stacking in GNOME VFS is achieved by using the # character, followed by
>the name of the next access method. For example, if the .tar is on a
>local file, you could use the following URI to combine the "tar" access
>method with the "file" one:
>file:/path/to/file.tar#tar/path/to/contained/file
>
>If the .tar was on an HTTP site for which authentication is required,
>you would use a URI like the following:
>
>  http://user:password@some.host.net/path/to/
>file.tar#tar/path/to/contained/file
>]]]
>         -- http://www.ximian.com/devzone/tech/gnome-vfs.html
>
>Ouch! Composition should go the other way, no?
>         tar:/file%3A%2Fpath%2Fto%2Ffile/path/to/contained/file
>
>or even:
>
>http://gnome.org/untar-svc?f=file%3A%2Fpath%2Fto%2Ffile;p=path/to/contained/file
>
>with special knowledge in gnome-smart clients that replies from
>gnome.org/untar-svc can be computed locally.
>
>--
>Dan Connolly, W3C http://www.w3.org/People/Connolly/

The linear order for stacking chould still be at the discretion of the language
in which it is being used.  It is not clear that entraining web references 
should make illegal the 'pipe' functionality, where subsequent transactions 
follow textually in the transaction description language.

On the other hand, owing to the principle that "anywhere you can use a 
URI-reference, you must be able to use any URI-reference" means that this 
practice, to wit using a URI-reference as a transaction request (a 
predicate clause) and adding a subsequent-transaction suffix by # as an 
infix operator is _not_ being a good neighbor in the Web.  It raises merry 
hob with Roy's fine work on enabling shared code in the parsing of 
arbitrary URI-references.

Some less conflicting notation should be arranged.

This application is actually in the domain of encodings and 
encoding-qualified references.

The problem here is that the path to be traveled here is partly visible in 
the clear and partly requires stripping the tar encoding of something which 
has an Internet address.

Transfer encodings can be added and removed in the HTTP processing without 
being mentioned at the application layer, but storage encodings, where the 
published URI implies the encoded form, requires explicit mention of the 
desired encoding state in a reference which crosses encoding levels in this 
way.

Invertible encodings such as tar are better dealt with in terms of 
declaring the desired encoding state rather than invoking an encoding or 
decoding method.

BUT that would require a binding encoding constraint in the language 
construct which embeds and employs the URI-reference, which goes against 
tradition on the Web.  We do need to overturn that tradition, but the TAG 
has not recognized this yet.

But the assertion of the required encoding state, rather than direction to 
decode, may be foreign to the Gnome culture.  But it's a better way to go.

Al
Received on Friday, 16 August 2002 14:15:45 UTC

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