From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH 1/2] Refactor digest authentication in url-auth Date: Mon, 14 Nov 2016 17:28:27 +0200 Message-ID: <83bmxihyhw.fsf@gnu.org> References: <1478988194-7761-1-git-send-email-jarno@malmari.fi> <1479036981-22047-1-git-send-email-jarno@malmari.fi> <1479036981-22047-2-git-send-email-jarno@malmari.fi> <83d1hzcr5r.fsf@gnu.org> <87shqvqc0b.fsf@malmari.fi> <83d1hyiv75.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1479137323 9765 195.159.176.226 (14 Nov 2016 15:28:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 14 Nov 2016 15:28:43 +0000 (UTC) Cc: jarno@malmari.fi, emacs-devel@gnu.org To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 14 16:28:39 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6JBK-0000P8-Ky for ged-emacs-devel@m.gmane.org; Mon, 14 Nov 2016 16:28:26 +0100 Original-Received: from localhost ([::1]:40842 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6JBN-00042g-PZ for ged-emacs-devel@m.gmane.org; Mon, 14 Nov 2016 10:28:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6JBD-0003ya-Ut for emacs-devel@gnu.org; Mon, 14 Nov 2016 10:28:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6JBA-0003eb-IV for emacs-devel@gnu.org; Mon, 14 Nov 2016 10:28:19 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6JBA-0003eU-Ep; Mon, 14 Nov 2016 10:28:16 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1880 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c6JB9-000291-Ny; Mon, 14 Nov 2016 10:28:16 -0500 In-reply-to: (message from Yuri Khan on Mon, 14 Nov 2016 10:34:18 +0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209385 Archived-At: > From: Yuri Khan > Date: Mon, 14 Nov 2016 10:34:18 +0600 > Cc: Jarno Malmari , Emacs developers > > >> > GNU coding standards frown on using "path" for anything but PATH-style > >> > directory lists. Please use "file name" or "directory name" instead. > >> > >> Good to know. Is there a convention to indicate path part in URIs? > > > > Not that I know of. I'd use "file-name part". > > To a network application developer, “path” is a domain[^1] term (RFC > 3986 § 3.3) and any replacement would be surprising and hinder API > discoverability. URIs don’t even necessarily map to files, so the > replacement proposed above is, in addition, misleading. The terminology in this case doesn't include "path", it includes "URI" and "abs_path" (see RFC 2617). The use of "path" in the doc strings being discussed should therefore be minimal, ideally zero. The clash with terminology accepted elsewhere is unfortunate, but nothing new: we have the same issues with "yank" vs "paste", "frame" vs "window", etc. GNU Coding Standards are mandatory for us, because GNU documentation is primarily for users of GNU software, who are accustomed to our terminology which is used consistently across projects. Therefore we should strive to use our terminology whenever we can, and if that requires some "creative" wording, so be it. > Please consider “URI path” if you must disambiguate. If needed, we should use "the path component of a URI" or somesuch. But ideally the need should not arise in this case at all, at least not AFAICT.