follow-up comments

diff --git a/doc/todo/pagespec_aliases.mdwn b/doc/todo/pagespec_aliases.mdwn
index 6a213de0c2770c925aa3ae317a43877ac894a61a..09155754cd5f8681065d6aec9c47deacb1bdad04 100644 (file)
--- a/doc/todo/pagespec_aliases.mdwn
+++ b/doc/todo/pagespec_aliases.mdwn
@@ -75,6 +75,9 @@ not sure whether I should name-grab 'alias' since [[todo/alias_directive]] is
 an existing wishlist item.
 
 > I think it would make sense to have "pagespec" in the name somehow.
 an existing wishlist item.
 
 > I think it would make sense to have "pagespec" in the name somehow.

+
+> > Good idea, how about `pagespecalias`? — [[Jon]]
+

 >
 > No, the strict/warnings does not make me puke. Have you read my perl
 > code? :-P
 >
 > No, the strict/warnings does not make me puke. Have you read my perl
 > code? :-P


@@ -86,7 +89,12 @@ an existing wishlist item.
 > Well, except that websetup doesn't currently support configuring hashes
 > like used here. Which is a pity, but has led me to try to avoid using
 > such hashes in the setup file.
 > Well, except that websetup doesn't currently support configuring hashes
 > like used here. Which is a pity, but has led me to try to avoid using
 > such hashes in the setup file.

-> 
+
+> > If I removed the `getsetup` subroutine, it would not be exposed via
+> > website, is that right?  I suppose it doesn't hurt to validate key, even if
+> > this risk was not there.  Is the use of a hash here a blocker for adoption?
+> > — [[Jon]]
+

 > Have you considered not defining the pagespec aliases in the setup file, but
 > instead as directives on pages in the wiki? Using pagestate could store
 > up the aliases that have been defined. It could however, be hard to get
 > Have you considered not defining the pagespec aliases in the setup file, but
 > instead as directives on pages in the wiki? Using pagestate could store
 > up the aliases that have been defined. It could however, be hard to get


@@ -94,6 +102,16 @@ an existing wishlist item.
 > an alias `foo` would need to somehow depend on the page where the alias
 > was defined. --[[Joey]] 
 
 > an alias `foo` would need to somehow depend on the page where the alias
 > was defined. --[[Joey]] 
 

+> > I haven't thought the dependency issue through beyond "that might be hard".
+> > Personally, I don't like defining stuff like this in pages, but I appreciate
+> > some do.  There could be some complex scenarios where some pages rely on a
+> > pagespec alias defined on others; and could have their meanings changed by
+> > changing the definition.  A user might have permission to edit a page with a
+> > definition on it but not on the pages that use it, and similar subtle permission
+> > bugs.  I'm also not sure what the failure mode is if someone redefines an alias,
+> > and whether there'd be an unpredictable precedence problem.
+> > How about both methods? — [[Jon]]
+

 Here's an example setup chunk:
 
      pagespec_aliases:
 Here's an example setup chunk:
 
      pagespec_aliases:


@@ -108,6 +126,8 @@ however, to add ' or internal()' to `boring`, for some reason.
 
 > Probably needs to be `or internal(*)` --[[Joey]] 
 
 
 > Probably needs to be `or internal(*)` --[[Joey]] 
 

+> > Ah yes, could be, thanks. — [[Jon]]
+

 > another useful pagespec alias for large maps:
 
        basewiki: "sandbox or templates or templates/* or ikiwiki or ikiwiki/* or shortcuts or recentchanges or wikiicons/*"
 > another useful pagespec alias for large maps:
 
        basewiki: "sandbox or templates or templates/* or ikiwiki or ikiwiki/* or shortcuts or recentchanges or wikiicons/*"


@@ -142,3 +162,7 @@ But [[plugins/contrib/report]] actually works without alteration because it does
 Unfortunately I haven't figured out how to do the dependencies - I'd really appreciate help on that.
 
 --[[KathrynAndersen]]
 Unfortunately I haven't figured out how to do the dependencies - I'd really appreciate help on that.
 
 --[[KathrynAndersen]]

+
+> > Cool!  I like the caching idea.  I'm not sure about the name.  I don't like defining
+> > stuff in pages, but I appreciate this is a matter of taste, and would be happy with
+> > supporting both. — [[Jon]]