From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hartwig Newsgroups: gmane.lisp.guile.bugs,gmane.lisp.guile.devel Subject: bug#12827: [PATCH] Tweak web modules, support relative URIs Date: Sun, 24 Feb 2013 20:31:58 +0800 Message-ID: References: <87vc9i6ld2.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1361709158 29394 80.91.229.3 (24 Feb 2013 12:32:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Feb 2013 12:32:38 +0000 (UTC) Cc: 12827@debbugs.gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Mark H Weaver Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sun Feb 24 13:33:00 2013 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U9alD-0003vM-65 for guile-bugs@m.gmane.org; Sun, 24 Feb 2013 13:32:55 +0100 Original-Received: from localhost ([::1]:38779 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9aks-0000RX-J3 for guile-bugs@m.gmane.org; Sun, 24 Feb 2013 07:32:34 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:43259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9ako-0000RN-QR for bug-guile@gnu.org; Sun, 24 Feb 2013 07:32:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U9akn-0006oP-62 for bug-guile@gnu.org; Sun, 24 Feb 2013 07:32:30 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9akn-0006oL-2X for bug-guile@gnu.org; Sun, 24 Feb 2013 07:32:29 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U9amH-0001yv-SI for bug-guile@gnu.org; Sun, 24 Feb 2013 07:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Hartwig Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 24 Feb 2013 12:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12827 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 12827-submit@debbugs.gnu.org id=B12827.13617092157587 (code B ref 12827); Sun, 24 Feb 2013 12:34:01 +0000 Original-Received: (at 12827) by debbugs.gnu.org; 24 Feb 2013 12:33:35 +0000 Original-Received: from localhost ([127.0.0.1]:46841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9alr-0001yJ-BA for submit@debbugs.gnu.org; Sun, 24 Feb 2013 07:33:35 -0500 Original-Received: from mail-ia0-f171.google.com ([209.85.210.171]:47752) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9alp-0001yC-9J for 12827@debbugs.gnu.org; Sun, 24 Feb 2013 07:33:34 -0500 Original-Received: by mail-ia0-f171.google.com with SMTP id z13so1748659iaz.16 for <12827@debbugs.gnu.org>; Sun, 24 Feb 2013 04:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=0K6epCKwAx520jHWximvqlTu9KxTOrWjcWxvbqG9P2c=; b=UHaXb4V10adHRv4EZLs44SdkMGWP3EfxucRQkFfEmcUSFFyuZGqOdscMgEMmDF48Rx cm0v01qvGMe3ztSdgbwpc2jCKm0OP/8xf/L/6qor9PmWinaok640N4G923mmdcW/o3To uoQrdERUOmsKmn9ikO491oIZzH8/X1GD8w+E7jI0OsOoJJvGpNKXGtQnp5y18cJjnhm5 jfbgX83s8zhAp0lsvYA5K8QNN2ehy5D1LaPaZcoQQxNFeIdKQV4ZE2IzxgfQfuoUt9TG A/8cL/699Ulpl1ie9wlyIYF0O96MjEEHZQFoQdPEYcM0nmjB/D7FAHadOFOq3vw9zUwH GsEw== X-Received: by 10.50.135.105 with SMTP id pr9mr1973797igb.6.1361709118960; Sun, 24 Feb 2013 04:31:58 -0800 (PST) Original-Received: by 10.64.26.168 with HTTP; Sun, 24 Feb 2013 04:31:58 -0800 (PST) In-Reply-To: <87vc9i6ld2.fsf@tines.lan> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:6771 gmane.lisp.guile.devel:15820 Archived-At: On 24 February 2013 18:45, Mark H Weaver wrote: > Hi Daniel, > > Daniel Hartwig 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 =E2=80=9Curi=E2=80=9D in their name. I did not > wish to introduce parallel =E2=80=9Cbuild-uri-reference=E2=80=9D, etc. fo= r 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 =E2=80=98uri-reference-path=E2=80=99 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, =E2=80=98uri?=E2=80=99 and =E2=80=98uri-referenc= e?=E2=80=99 are the predicates and they respond according to the RFC rather than internal Guile details? That is: (uri? (string->uri-reference "http://example.net/")) =3D> #t (uri-reference? (string->uri-reference "http://example.net/")) =3D> #t (uri? (string->uri-reference "foo")) =3D> #f or =E2=80=A6? > 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= ? :-) .