Re: Fwd: Re: URIs vs. half-baked URIs [glib PATCH]

[Daniel Veillard <veillard redhat com>]

  Well I misread that part.
  However using file:///path is I think a better practice than
file:/path . Though file:/path is a hierachical URI per the RFC 2396
the RFC 1738 defining the file scheme in section 3.10 explictely say

----------------------
 A file URL takes the form:

    file://<host>/<path>
----------------------
and
----------------------
 As a special case, <host> can be the string "localhost" or the empty
 string; this is interpreted as `the machine from which the URL is
 being interpreted'.
----------------------

  Though it is a bit ancient, it's probably a good idea to stay compatible
with it, and I think that's should be the preffered form.

Daniel

On Fri, Aug 24, 2001 at 01:26:41PM -0700, Waldo Bastian wrote:
> Hi Daniel,
> 
> I fail to understand you. Are you saying that absolute URIs like
> file:/home/devel/alexl/all_types.c are broken and that they should be
> file:///home/devel/alexl/all_types.c ?
> 
> You make references to some sections in RFC 2396 but I fail to see the 
> relevance of that. Maybe I'm missing parts of the discussion though, please 
> explain.
> 
> Cheers,
> Waldo Bastian
> KURL Maintainer.
> 
> On Friday 24 August 2001 01:04 pm, Guillaume Laurent wrote:
> > ----------  Forwarded Message  ----------
> >
> > Subject: Re: URIs vs. half-baked URIs [glib PATCH]
> > Date: Fri, 24 Aug 2001 15:18:22 -0400
> > From: Daniel Veillard <veillard redhat com>
> > To: Alex Larsson <alexl redhat com>
> > Cc: Darin Adler <darin bentspoon com>, gtk-devel-list gnome org,
> > gnome-hackers gnome org
> >
> > On Fri, Aug 24, 2001 at 12:05:11PM -0400, Alex Larsson wrote:
> > > I copied the current behaviour from gnome-vfs. Konqueror gives URIs like
> > > "file:/home/devel/alexl/all_types.c", maybe we should too.

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/