Hmmmm I don't think I agree. I think a *VERSION* of the URI spec would
be the best way of giving platform independence with the benefit of
being able to handle http, ftp, files, etc in a transparent way.
If you look at the URI spec it is very simple. Really the base URI
spec only specifies a few things, a character set that is valid (with
the ability to escape reserved characters), a scheme (file, http,
ftp), an authority (usually host name), and a path.
I want to basically say (syntax is just an example):
f := ( File fromURI: 'file:///blah/foo/myfile.txt' ).
f bytes (or size).
f isReadable.
f isWriteable.
f isExecutable.
f makeWritableByAnyone.
f openReadOnly.
Where f is a File object or a Directory object. These objects talk via
a Bridge object to the OS.
Now change the initial string name to be an http address. Everything
should keep working with NO changes (well as little as possible). Same
File or Directory object is returned (or maybe a FtpFile ).
I think some people are getting stuck on a URI as they are used by the
web. There is nothing that says a URI is read only or writeable or in
fact anything other than an identifier (Uniform Resource Identifiers).
The following is taken from http://www.ietf.org/rfc/rfc2396.txt just
ignore the fact that their examples use http, the "file" scheme is
handled the same way. The base URI would be the directory that the
image starting in. ----------------------------------------------------
-----------------------
   The following line is the regular expression for breaking-down a URI
   reference into its components.
      ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
       12            3  4          5       6  7        8 9
   The numbers in the second line above are only to assist readability;
   they indicate the reference points for each subexpression (i.e.,
   each paired parenthesis).  We refer to the value matched for
   subexpression <n> as $<n>.  For example, matching the above
   expression to
      http://www.ics.uci.edu/pub/ietf/uri/#Related
   results in the following subexpression matches:
      $1 = http:
      $2 = http
      $3 = //www.ics.uci.edu
      $4 = www.ics.uci.edu
      $5 = /pub/ietf/uri/
      $6 = <undefined>
      $7 = <undefined>
      $8 = #Related
      $9 = Related
   where <undefined> indicates that the component is not present, as is
   the case for the query component in the above example.  Therefore,
   we can determine the value of the four components and fragment as
      scheme    = $2
      authority = $4
      path      = $5
      query     = $7
      fragment  = $9
   and, going in the opposite direction, we can recreate a URI
   reference from its components using the algorithm in step 7 of
   Section 5.2.
C. Examples of Resolving Relative URI References
   Within an object with a well-defined base URI of
      http://a/b/c/d;p?q
   the relative URI would be resolved as follows:
C.1.  Normal Examples
      g:h           =  g:h
      g             =  http://a/b/c/g
      ./g           =  http://a/b/c/g
      g/            =  http://a/b/c/g/
      /g            =  http://a/g
      //g           =  http://g
      ?y            =  http://a/b/c/?y
      g?y           =  http://a/b/c/g?y
      #s            =  (current document)#s
      g#s           =  http://a/b/c/g#s
      g?y#s         =  http://a/b/c/g?y#s
      ;x            =  http://a/b/c/;x
      g;x           =  http://a/b/c/g;x
      g;x?y#s       =  http://a/b/c/g;x?y#s
      .             =  http://a/b/c/
      ./            =  http://a/b/c/
      ..            =  http://a/b/
      ../           =  http://a/b/
      ../g          =  http://a/b/g
      ../..         =  http://a/
      ../../        =  http://a/
      ../../g       =  http://a/g