[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Tweak web modules, support relative URIs
From: |
Daniel Hartwig |
Subject: |
Re: [PATCH] Tweak web modules, support relative URIs |
Date: |
Sun, 24 Feb 2013 20:31:58 +0800 |
On 24 February 2013 18:45, Mark H Weaver <address@hidden> wrote:
> Hi Daniel,
>
> Daniel Hartwig <address@hidden> writes:
>> * Terminology
>>
>> The terminology used in latest URI spec. (RFC 3986) is not widely used
>> elsewhere. Not by Guile, not by the HTTP spec., or other sources.
>> Specifically, it defines these terms:
>>
>> - URI: scheme rest ... [fragment]
>> - Absolute-URI: scheme rest ... [fragment]
>> - Relative-Ref: rest ... [fragment]
>> - URI-Reference: Absolute-URI | Relative-Ref
>>
>> where as HTTP and other sources use the terms from an earlier URI
>> spec. (RFC 2396):
>>
>> - Absolute-URI: scheme rest ... [fragment]
>> - Relative-URI: rest ... [fragment]
>> - URI, URI-Reference: Absolute-URI | Relative-URI
>>
> My preference would be to use the newer RFC 3986 terms. To my mind, the
> key question is: which type (Absolute-URI or URI-Reference) is more
> commonly appropriate in user code, and thus more deserving of the short
> term "URI".
>
> I would argue that Absolute-URIs are more often appropriate in typical
> user code. The reason is that outside of URI-handling libraries, most
> code that deals with URIs simply use them as universal pointers,
> i.e. they implicitly assume that each URI is sufficient by itself to
> identify any resource in universe.
Right. RFC 3986 makes a convincing argument for the new terminology.
These notes about usage also reflect the sentiment in that document.
FWIW, I sat mostly on the fence, finally going away from URI-Reference
due to these concerns I expressed in an earlier email:
> The API seems less clean, and it is not immediately clear
> that uri? is not the top of the URI-like type hierarchy. The other
> functions only indicate “uri” in their name. I did not
> wish to introduce parallel “build-uri-reference”, etc. for each of
> these, and did consider adding #:reference? on some to select
> weaker validation.
and looking at some other Scheme URI modules.
However, having read over your comments I think that we could
reasonably get away with just introducing the procedures you mention
below and not bother about renaming (or duplicating) the field getters
to ‘uri-reference-path’ etc..
> Here's what I suggest: instead of extending 'string->uri' and
> 'build-uri' to produce relative URIs, rename those extended procedures
> 'string->uri-reference' and 'build-uri-reference'. These are long
> names, but that's okay because users should think twice before using
> them, and that's seldom needed.
In your proposed solution, ‘uri?’ and ‘uri-reference?’ are the
predicates and they respond according to the RFC rather than internal
Guile details? That is:
(uri? (string->uri-reference "http://example.net/"))
=> #t
(uri-reference? (string->uri-reference "http://example.net/"))
=> #t
(uri? (string->uri-reference "foo"))
=> #f
or …?
> Then, we extend 'string->uri' and 'build-uri' in a different way: we
> extend them to handle relative references in their *inputs*, but
> continue to provide absolute *outputs*, by adding an optional keyword
> argument '#:base-uri'. This would make it easy to implement the
> simplest and safest strategy outlined above with a minimum of code
> changes.
This strategy does reflect the recommendation of RFC 3986 to resolve
the references as they are read. Also an elegant API, as it
encourages immedately resolving uri-references and never creating (or
considering to create) the context-sensitive relative-refs.
>
> What do you think?
>
I quite like it, particularly the last part about #:base-uri.
Ludo, I think this is basically what you were suggesting in the first place? :-)
.