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 14:55:54 -0500 Message-ID: <87mwut7agl.fsf__16066.8154167526$1361735822$gmane$org@tines.lan> 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 1361735799 24697 80.91.229.3 (24 Feb 2013 19:56:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Feb 2013 19:56: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 20:57: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 1U9hgx-000722-Rg for guile-bugs@m.gmane.org; Sun, 24 Feb 2013 20:57:00 +0100 Original-Received: from localhost ([::1]:54758 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9hgd-0006Mf-BL for guile-bugs@m.gmane.org; Sun, 24 Feb 2013 14:56:39 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:38738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9hgY-0006MG-2V for bug-guile@gnu.org; Sun, 24 Feb 2013 14:56:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U9hgR-0004Al-AE for bug-guile@gnu.org; Sun, 24 Feb 2013 14:56:34 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42516) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9hgR-0004Ad-6E for bug-guile@gnu.org; Sun, 24 Feb 2013 14:56:27 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U9hhx-0005DG-K4 for bug-guile@gnu.org; Sun, 24 Feb 2013 14:58:01 -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 19:58: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.136173586920019 (code B ref 12827); Sun, 24 Feb 2013 19:58:01 +0000 Original-Received: (at 12827) by debbugs.gnu.org; 24 Feb 2013 19:57:49 +0000 Original-Received: from localhost ([127.0.0.1]:47980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9hhk-0005Cp-P7 for submit@debbugs.gnu.org; Sun, 24 Feb 2013 14:57:49 -0500 Original-Received: from world.peace.net ([96.39.62.75]:57152) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9hhh-0005Ch-LQ for 12827@debbugs.gnu.org; Sun, 24 Feb 2013 14:57:47 -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 1U9hg2-0005Vv-6a; Sun, 24 Feb 2013 14:56:02 -0500 In-Reply-To: (Daniel Hartwig's message of "Sun, 24 Feb 2013 20:31:58 +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:6780 Archived-At: Daniel Hartwig writes: > On 24 February 2013 18:45, Mark H Weaver wrote: >> 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. f= or 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.. Hmm. The cleanest solution would probably be to duplicate the field getters, and make the 'uri-*' variants (e.g. 'uri-path') raise an error when applied to a relative reference. However, it's probably not that important, so if you think it's better to simply extend 'uri-path' etc to apply to all URI-References, I'm okay with that. >> 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-refere= nce?=E2=80=99 are the > predicates and they respond according to the RFC rather than internal > Guile details? What do you mean by "rather than internal Guile details"? Here's how I like to think about these types: URI-Reference is at the top of the type hierarchy, and URI (a.k.a. Absolute-URI) and Relative-Ref are subtypes. Furthermore, every URI-Reference is either an Absolute-URI or a Relative-Ref. In other words, if you create a URI-Reference that happens to be absolute, then you'll end up with a URI, in the same sense that if you create a complex number whose imaginary part happens to be exact zero, you'll end up with a real number. > 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 Yes. >> 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 pla= ce? :-) Excellent! BTW, to be clear, I suggest that 'string->uri' and 'build-uri' should be guaranteed to produce Absolute-URIs. In other words, they should raise an error if not given enough information to produce an Absolute-URI. Does that make sense? Thanks again for your work on this :) Mark