[ Forwarding to list, with permission ]
C. Michael Pilato wrote on Fri, Aug 09, 2013 at 10:06:25 -0400:
> On 08/09/2013 03:06 AM, Daniel Shahaf wrote:
> >> Ooh... option 3 is kind cool, and your use-case isn't particularly
> >> far-fetched. Though, I think if I were an administrator, I'd probably
> >> want to smack someone for divorcing the "here's the data" and "here's
> >> how you interpret the data" constructs like this. Seems like it might
> >> lead to some confusion.
> >
> > That is true. I realised that point, and I also came up with
> > a counter-point for it: "do one thing and do it well". SVNPath is the
> > data and SVNPathOptions is the interpretation; there's no need to start
> > guessing whether the argument is a path string, or a space-separated
> > options string followed by a path string. This is here and that is
> > there.
>
> Hrm... In all realistic use-cases I can conceive, no one would tweak
> the SVNPathOptions for a <Location> without also tweaking SVNPath
> itself. It's not as if you're going to have a single pathspec that's
> sometimes a template, sometimes a literal path, sometimes a virtual
> path, etc. Furthermore, of the various modifiers we've discussed, there
> are two distinct classes:
>
Does anyone use SVNPath outside of a <Location> block? The directive's
declaration permits that (includes RSRC_CONF), but we don't document it.
(See next hunk...)
> * those which change how the path string is interpreted: literal (the
> default), template, virtual
>
> * those which change how the interpreted path string is applied and
> used: repository path, repos parent path
>
Agreed with this distinction. And to answer my own question above, it
would be sensible to use SVNPath at global scope and a modifier of the
"post-interpretation" kind in Location scope; for example, it would be
entirely reasonable to set any of
SVNPathOptions isparent=off
SVNPathOptions anonymous_commits=off
SVNPathOptions readonly=on
in Location scope, without changing (or, indeed, knowing) the
SVNPath/SVNParentPath value.
> Maybe the way to go here is to keep both SVNPath and SVNParentPath, take
> advantage of the need to escape whitespace in the pathspec, and simply
> add the optional modifier strings "template" or "virtual" to the ends of
> both directives:
>
> SVNPath pathspec ["template"|"virtual"|...]
> SVNParentPath pathspec ["template"|"virtual"|...]
>
> Thoughts?
I'm sold on the distinction between "Knobs that affect the path string
interpretation" knobs and "post-interpretation" knobs. As to whether we
keep SVNPath and SVNParentPath directives separate, versus have one
directive that contains the pathspec + interpretation options and
another directive that contains the post-interpretation options, I am
not sure.
For the sake of concreteness, I suggest:
1. Add "template|virtual|..." to SVNPath (use "unescaped whitespace"
as a mode selector, per earlier discussion) and deprecate SVNParentPath.
2. Add SVNPathOptions directive with knobs:
isparent=[on|off]
anonymous=[""|"r"|"rw"]
readonly=[on|off]
WDYT?
Daniel
P.S. Should we move this to dev@? I don't mind if this email is quoted
on a public list.
P.P.S. In case I need to motivate the "anonymous=r" SVNPathOption
I suggested: the existing ways to make a repository read-only by
unauthenticated users involve either setting up an authz file or an
unwieldy <LimitExcept> block. As a configurer I'd be very happy to have
a very clear statement: "This <Location> is read-only to unauthenticated
users." mod_dav_svn can figure out the LimitExcept blacklist for me and
apply it.
