From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.devel Subject: Re: port-filename and path canonicalization Date: Thu, 22 Apr 2010 09:42:57 +0200 Message-ID: <87tyr40w72.fsf@ambire.localdomain> References: <878w8jyr3w.fsf@gnu.org> <87tyr69xyt.fsf@ambire.localdomain> <87mxwxjim6.fsf@gnu.org> <87aaswd3ap.fsf@ambire.localdomain> <87tyr4tpb0.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1271931454 20686 80.91.229.12 (22 Apr 2010 10:17:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Apr 2010 10:17:34 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Apr 22 12:17:33 2010 connect(): No such file or directory Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O4tTR-0001rZ-Gb for guile-devel@m.gmane.org; Thu, 22 Apr 2010 12:17:33 +0200 Original-Received: from localhost ([127.0.0.1]:50782 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4tTQ-0001UF-Qf for guile-devel@m.gmane.org; Thu, 22 Apr 2010 06:17:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4tSh-0001Jw-Uk for guile-devel@gnu.org; Thu, 22 Apr 2010 06:16:48 -0400 Original-Received: from [140.186.70.92] (port=45888 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4tSe-0001Ih-By for guile-devel@gnu.org; Thu, 22 Apr 2010 06:16:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4r5I-0003PJ-Nm for guile-devel@gnu.org; Thu, 22 Apr 2010 03:44:35 -0400 Original-Received: from host25-71-dynamic.41-79-r.retail.telecomitalia.it ([79.41.71.25]:33330 helo=ambire.localdomain) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4r5F-0003NS-HR for guile-devel@gnu.org; Thu, 22 Apr 2010 03:44:26 -0400 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1O4r3q-0002zt-8D for guile-devel@gnu.org; Thu, 22 Apr 2010 09:42:58 +0200 In-Reply-To: <87tyr4tpb0.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Thu, 22 Apr 2010 00:26:43 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:10283 Archived-At: () ludo@gnu.org (Ludovic Court=C3=A8s) () Thu, 22 Apr 2010 00:26:43 +0200 > That is, if a file port supports =E2=80=98file-port-directory=E2=80=99= , then how > to use/restrict the resulting object is left up to higher layers, > where it belongs. I would put it the other way round: if an application wants to implement =E2=80=98file-port-directory=E2=80=99, then it=E2=80=99s its r= esponsibility to associate the necessary information (and authority) with open file ports (those under its control, that is.) It=E2=80=99s an application of the principle of least authority. Sure, given the model that access and authority are equivalent. My point is that it is possible to use a model where they aren't. A system that supports the latter model can build the former on top. But a system that supports only the former model can only fake the latter model, later. It's always easier to combine separate things later than to separate conflated things later. The canonicalization wranglings highlight this. Canonicalization is a high-level concept needed because the low-level access was not granular enough. A filename with directory components of an already validated (opened, accessed, processed in the Right Way) file implies that all the parent directories have also *already* been validated (in their own way). But that, and related, information is lost, so we need to canonicalize in order to re-validate those portions. If that directory information is saved (simple internal caching), these particular recomputations are avoidable. If that directory information is available to the application (reified and appropriately sanitized), the application can layer authority measures as it sees fit (as you state in the first paragraph, IIUC), in addition to enjoying the efficiency gain, and the need for canonicalization disappears. (Actually, the need for canonicalization disappears even with simple internal caching, but since the context of this discussion is process B finding neighbors to a file created by process A, it is no longer an internal matter. Or perhaps that's just me jumping ahead (i've got bugs, debuggers and debugging file formats on the mind lately)?) OK, back to the grindstone. I'm digging my way out RCS duties (one might view this as preparation for History Objects ;-) right now, but hopefully will be able to transform word spew to code spew (for Guile) in the next several weeks. A last parting word/pointer on this thread re "path": (info "(standards) GNU Manuals") thi