[ Just changing the subject. The background is the branch cmpilato
started a couple of days ago; I'll let him introduce that. ]
Daniel Shahaf wrote on Fri, Aug 09, 2013 at 17:37:46 +0300:
> [ 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.
Received on 2013-08-09 16:40:45 CEST