Re: [PATCH 1/2] Refactor digest authentication in url-auth

[Eli Zaretskii <eliz@gnu.org>]

> From: Jarno Malmari <jarno@malmari.fi>
> Cc: emacs-devel@gnu.org
> Date: Sun, 13 Nov 2016 23:57:08 +0200
> 
> > * lisp/url/url-auth.el (url-digest-auth, url-digest-auth-create-key):
> > (url-digest-auth-build-response, url-digest-auth-directory-id-assoc)
> > (url-digest-auth-name-value-string, url-digest-auth-source-creds)
> > (url-digest-cached-key, url-digest-cache-key, url-digest-find-creds)
> > (url-digest-find-new-key, url-digest-prompt-creds): Add new functions to
> > simplify code and aid in unit testing.
> >
> > IOW, each line begins is separately parenthesized.
> 
> Will fix. Seems I wasn't able to deduce the correct format from previous
> log entries nor from the CONTRIBUTE file. Is this format obvious to
> others? Should the "each line separately parenthesized" be described in
> the CONTRIBUTE file?

CONTRIBUTE says to use ChangeLog commands, like "C-x 4 a", to add the
entries.  Those commands produce the above format automatically.

> >> +(defun url-digest-auth-directory-id-assoc (dirkey keylist)
> >> +  "Find the best match in key list using a path or a realm.
> >> +
> >> +The string DIRKEY is either a path or a realm.  The key list to
> >> +search through is the alist KEYLIST where car of each element is
> >> +either a path or a realm.  Realms are searched for an exact
> >> +match.  For paths, an ancestor is sufficient for a match."
> >
> > 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".

> >> +   ;; no partial matches for non-path, i.e. realm
> >> +   (and (string-match "/" dirkey)
> >
> > This will fail with Windows file names that use backslashes.
> 
> We're actually not talking about file system paths. We're talking about
> paths (directory names?) in URIs which define, together with realm, the
> "protection space" (see RFC2617 ;)).

Ah, okay.  In that case, this should be described in more detail, I
think.

Note that there's also an Info manual for the URL package.

> >> +    ;; if incomplete and prompt allowed, prompt the user
> >
> > Comments should begin with a capital letter and end with a period, as
> > normal sentences are (here and elsewhere in the patch).
> 
> Does that implicitly mean that each comment should be a complete
> sentence?

Yes, preferably.

Thanks.