[ 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.
