From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.bugs Subject: bug#12827: [PATCH] Tweak web modules, support relative URIs Date: Sun, 24 Feb 2013 05:45:45 -0500 Message-ID: <87vc9i6ld2.fsf__25157.3724359789$1361702822$gmane$org@tines.lan> References: 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 1361702799 11451 80.91.229.3 (24 Feb 2013 10:46:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Feb 2013 10:46:39 +0000 (UTC) Cc: 12827@debbugs.gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Daniel Hartwig Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sun Feb 24 11:47:01 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 1U9Z6b-0003wy-Qx for guile-bugs@m.gmane.org; Sun, 24 Feb 2013 11:46:54 +0100 Original-Received: from localhost ([::1]:42361 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9Z6H-0002AJ-AI for guile-bugs@m.gmane.org; Sun, 24 Feb 2013 05:46:33 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9Z6E-0002AC-Tk for bug-guile@gnu.org; Sun, 24 Feb 2013 05:46:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U9Z6D-0005Qx-QC for bug-guile@gnu.org; Sun, 24 Feb 2013 05:46:30 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9Z6D-0005Qt-Mn for bug-guile@gnu.org; Sun, 24 Feb 2013 05:46:29 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U9Z7i-0006yJ-54 for bug-guile@gnu.org; Sun, 24 Feb 2013 05:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 24 Feb 2013 10:48:02 +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.136170285726768 (code B ref 12827); Sun, 24 Feb 2013 10:48:02 +0000 Original-Received: (at 12827) by debbugs.gnu.org; 24 Feb 2013 10:47:37 +0000 Original-Received: from localhost ([127.0.0.1]:46797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9Z7J-0006xg-Di for submit@debbugs.gnu.org; Sun, 24 Feb 2013 05:47:37 -0500 Original-Received: from world.peace.net ([96.39.62.75]:56699) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9Z7G-0006xT-LG for 12827@debbugs.gnu.org; Sun, 24 Feb 2013 05:47:35 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U9Z5d-0004Ao-Gz; Sun, 24 Feb 2013 05:45:53 -0500 In-Reply-To: (Daniel Hartwig's message of "Sat, 23 Feb 2013 16:11:18 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) 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:6769 Archived-At: 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 > > With this patch I have opted to use the later, more common terms. > This has the advantage of not requiring massive renaming or > duplicating of most procedures to include, e.g. > =E2=80=98uri-reference-scheme=E2=80=99, as we just use the term =E2=80=98= uri=E2=80=99 to refer to > either type. > > If this is undesired, it can easily be reworked to use the terminology > from RFC 3986. Thanks for your careful work on this, and especially for calling our attention to the terminology changes introduced in the latest URI spec. 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. Working with URI-References is inherently trickier and more error-prone, because code that handles them must do some additional bookkeeping to associate each URI-Reference with its _context_. It is inconvenient to mix URI-References from different contexts, and they must be converted when moved from one context to another. For typical code, the simplest and safest strategy for dealing with URI-References is to convert them to Absolute-URIs as early as possible, preferably as the document is being read. (Of course, there are special cases such as editors where it is important to preserve the URI-References, but that is not the typical case). Therefore, I think that Absolute-URI is more deserving of the short term "URI", and furthermore that existing code outside of (web uri) that refers to URIs should, by default, be assumed to be talking about Absolute-URIs. Only after some thought about whether a procedure handles relative references properly should its type be changed to accept URI-References. > * API compatability > > Presently, all APIs work only with absolute URIs. You can not use > string->uri or build-uri to produce any relative URIs, neither are > other procedures (generally) expected to work correctly if given them. For the reasons given above, I think that it is a virtue, not a flaw, i.e. I think that latest URI spec (RFC 3986) got this right.=20=20 It is important to clearly distinguish Absolute-URIs from URI-References. Despite their overlapping syntax, they are very different concepts, and must not be conflated. 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. 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. What do you think? Mark