From: Joey Hess Date: Wed, 7 Oct 2009 17:36:40 +0000 (-0400) Subject: Merge branch 'master' into dependency-types X-Git-Tag: 3.20091017~27^2~82 X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/commitdiff_plain/0ebb44955aaf454974b9e92f23539bd0e83aee59?ds=sidebyside;hp=-c Merge branch 'master' into dependency-types --- 0ebb44955aaf454974b9e92f23539bd0e83aee59 diff --combined doc/todo/dependency_types.mdwn index 4bc38e9c0,9d649e1e0..74d58a9e5 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@@ -170,6 -170,11 +170,11 @@@ I added an "add_depends_spec()" functio changes, then the dependent page is rebuilt. At the moment the implementation uses the same hack used by map and inline - just add all the pages that currently exist as traditional content dependencies. + > As I note below, a problem with this approach is that it has to try + > matching the pagespec against every page, redundantly with the work done + > by the plugin. (But there are ways to avoid that redundant matching.) + > --[[Joey]] + Getting back to commenting on your proposal: Just talking about the definition of a "presence dependency" for the moment, and ignoring implementation. Is a @@@ -180,6 -185,11 +185,11 @@@ after `test_page`. `new_page` will no `new_page` will match the spec, and yet `new_page` itself hasn't changed. Nor has its 'presence' - it was present before and it is present now. Should this cause a re-build of any page that has a 'presence' dependency on the spec? + > Yes, a presence dep will trigger when a page is added, or removed. + + > Your example is valid.. but it's also not handled right by normal, + > (content) dependencies, for the same reasons. --[[Joey]] + I think that is another version of the problem you encountered with meta-data. In the longer term I was thinking we'd have to introduce a concept of 'internal pagespec dependencies'. Note that I'm @@@ -217,13 -227,29 +227,26 @@@ sigh -- [[Will]] + > I have also been thinking about some sort of analysis pass over pagespecs + > to determine what metadata, pages, etc they depend on. It is indeed + > tricky to do. Even if it's just limited to returning a list of pages + > as you suggest. + > + > Consider: For a `*` glob, it has to return a list of all pages + > in the wiki. Which is expensive. And what if the pagespec is + > something like `* and backlink(index)`? Without analyising the + > boolean relationship between terms, the returned list + > will have many more items in it than it should. Or do we not make + > globs return their matches? (If so we have to deal with those + > with one of the other methods disucssed.) --[[Joey]] + ---- ### Link dependencies * `add_depends($page, $spec, links => 1, presence => 1)` adds a links + presence dependency. -* `refresh` only rebuilds a page with a links dependency if - pages matched by the pagespec gain or lose links. (What the link - actually points to may change independent of this, due to changes - elsewhere, without it firing.) +* Use backlinks change code to detect changes to link dependencies too. * So, brokenlinks can fire whenever any links in any of the pages it's tracking change, or when pages are added or removed. @@@ -233,7 -259,6 +256,7 @@@ that the page links to, which is just what link dependencies are triggered on. +[[done]] ---- ### the removal problem @@@ -257,9 -282,22 +280,22 @@@ we grew the complication of `depends_si One way to fix this is to include with each dependency, a list of pages that currently match it. If the list changes, the dependency is triggered. - Should be doable, but seems to involve a more work than + Should be doable, but may involve more work than currently. Consider that a dependency on "bugs/*" currently is triggered by just checking until *one* page is found to match it. But to store the list, *every* page would have to be tried against it. Unless the list can somehow be intelligently updated, looking at only the - changed pages. + changed pages. + + ---- + + What if there were a function that added a dependency, and at the same time + returned a list of pages matching the pagespec? Plugins that use this would + be exactly the ones, like inline and map, for which this is a problem, and + which already do a match pass over all pages. + + Adding explicit dependencies during this pass would thus be nearly free. + Not 100% free since it would add explicit deps for things that are not + shown on an inline that limits its display to the first sorted N items. + I suppose we could reach 100% free by making the function also handle + sorting and limiting, though that could be overkill.