Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

doc/bugs/websetup_eats_setupconf_and_allow__95__symlinks__95__before__95__srcdir.mdwn

@@ -17,4 +17,5 @@ Sorry for the confusion.
 > which will be at best redundant.
 > 
 > Can you find another solution, such as a symlink, for your special case?
-> --[[Joey]]
+
+I see your point. [[done]]

doc/todo/ACL.mdwn

@@ -23,6 +23,24 @@ something, that I think is very valuable.
 
 Also see [[!debbug 443346]].
 
+> Just a few quick thoughts about this:
+>
+>* I'm only thinking about write ACLs.  As Joey noted, read ACLs need to be done in the web server.
+>* ACLs are going to be really hard for people with direct access to the revision control system.
+>  Which means that we really only need to define ACLs for web access.
+>* ACLs for web access can then be defined by the web master.  These might not need to be
+>  defined in the wiki pages (although they could be).
+>* Given the previous two points, can't this be done with the `match_user()`
+> function defined by the [[plugins/attachment]] plugin (see the [[ikiwiki/pagespec/attachment]] pagespec info)
+> and the [[plugins/lockedit]] plugin (see [[page_locking]])?
+>
+> For example, add the following to your config file:
+>
+> locked_pages => '!(user(john) and */Discussion) and *',
+>
+> would lock all pages unless you're john and editing a Discussion page.
+> It's a thought anyway :-).  -- [[Will]]
+
 I am considering giving this a try, implementing it as a module.
 Here is how I see it:
 

doc/todo/fastcgi_or_modperl_installation_instructions.mdwn

@@ -0,0 +1 @@
+There has got to be a way to run the CGI wrapper under fastcgi or modperl (apache 2). Are there easy to follow instructions describing how to set this up?

doc/todo/progressbar_plugin.mdwn

@@ -128,3 +128,5 @@ Any comments? --[[Paweł|ptecza]]
 >>>>> --[[Paweł|ptecza]]
 
 >>>>>> Reviewed, looks excellent, added. [[done]] --[[Joey]]
+
+>>>>>>> Thanks a lot for you and Will! :) [[Paweł|ptecza]]

doc/todo/structured_page_data.mdwn

@@ -69,3 +69,37 @@ Additional tie-ins:
 See also:
 
 [[tracking_bugs_with_dependencies]]
+
+> I was also thinking about this for bug tracking.  I'm not sure what
+> sort of structured data is wanted in a page, so I decided to brainstorm
+> use cases:
+>
+> * You just want the page to be pretty.
+> * You want to access the data from another page.  This would be almost like
+>     like a database lookup, or the OpenOffice Calc [VLookup](http://wiki.services.openoffice.org/wiki/Documentation/How_Tos/Calc:_VLOOKUP_function) function.
+> * You want to make a pagespec depend upon the data.  This could be used
+>    for dependancy tracking - you could match against pages listed as dependencies,
+>    rather than all pages linked from a given page.
+>
+>The first use case is handled by having a template in the page creation.  You could
+>have some type of form to edit the data, but that's just sugar on top of the template.
+>If you were going to have a web form to edit the data, I can imagine a few ways to do it:
+>
+> * Have a special page type which gets compiled into the form.  The page type would
+>    need to define the form as well as hold the stored data.
+> * Have special directives that allow you to insert form elements into a normal page.
+>
+>I'm happy with template based page creation as a first pass...
+>
+>The second use case could be handled by a regular expression directive. eg:
+>
+> \[[regex spec="myBug" regex="Depends: ([^\s]+)"]]
+>
+> The directive would be replaced with the match from the regex on the 'myBug' page... or something.
+>
+>The third use case requires a pagespec function.  One that matched a regex in the page might work.
+>Otherwise, another option would be to annotate links with a type, and then check the type of links in
+>a pagespec.  e.g. you could have `depends` links and normal links.
+>
+>Anyway, I just wanted to list the thoughts.  In none of these use cases is straight yaml or json the
+>obvious answer.  -- [[Will]]