Re: Massive gnome-vfs proposal.

[jrb redhat com]

> jrb@redhat.com writes:
> 
> > Hi guys,
> > 
> > In gnome-vfs, the basic file unit is the GnomeVFSURI struct, which
> > contains all the necessary information needed to resolve a url.  The
> > problem is, strictly speaking, a URI doesn't necessarily have all the
> > information about resolution built in.  (URN's, for example, need to be
> > resolved externally.) 
> 
> I'm not sure what you mean by this. Yes, URNs are more complicated to
> resolve than URIs. But why does this imply that a URI doesn't have all
> the information about resolution built in?

b/c knowing a URN is independent of knowing how to resolve it.  The URL's
that we pass into gnome-vfs inherently have the resolution built in, by
having the transport built in.  Ie. we pass in something like:

file:/tmp/foo.tar.gz#tar:/path/file#gzip:

with a URN, the resolution is not defined.


> > As a result, I'd like to rename GnomeVFSURI to be GnomeVFSURL, which
> > is a more appropriate name.
> 
> The set of URIs is the set of URLs and the set of URNs, so every URL
> is also a URI. Maybe you are saying that GnomeVFSURI is intrinsically
> incapable of handling URNs, but I don't agree; I don't see why
> urn-method.c could not be written by a sufficiently enterpsising/crazy
> person.

It certainly could be done, but it wouldn't be as nice, both
programmatically and conceptially.  You would basically have to do the
resolution every time an operation occurred (or cache the result in the
module!) and perform the actual chaining by hand. 

> > Additionally, we need an
> > additional step that could let us do the URI->URL conversion.  This way
> > we can add a real GnomeVFSURI struct that looks something like:
> 
> I don't think it's the case that every URN must have an associated
> URL. In fact, URNs must remain globally unique and in some sense
> `valid' even when the resource they point to is not accessible through
> any URL, or even no longer existant.

That's true.

-Jonathan