]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/commitdiff
remove highlevel influence calculation stuff
authorJoey Hess <joey@gnu.kitenet.net>
Fri, 9 Oct 2009 21:19:07 +0000 (17:19 -0400)
committerJoey Hess <joey@gnu.kitenet.net>
Fri, 9 Oct 2009 21:19:07 +0000 (17:19 -0400)
I have it implemented in both add_depends and pagespec_match_list.
The add_depends implementation is optimised to only try one page
if the pagespec's influences are all static, and do not vary by page
matched.

doc/todo/dependency_types.mdwn

index 6ca06fdabbd089f48d3eab55a1d9d718cc937c97..e95965c3325fffffd32ee2988a4fd1526458188a 100644 (file)
@@ -564,57 +564,6 @@ SuccessReason(page, index) => right
 `HardFailReason() | SuccessReason(bugs/foo)` =>  
 `HardFailReason()` => right
 
-#### High-level Calculation and Storage
-
-Naively calculating the full influence list for a pagespec requires trying
-to match it against every page in the wiki. I'd like to avoid doing such
-expensive matching redundantly.
-
-It may be possible, for some types of pagespecs, to just try matching a
-single, arbitrary page against it, and know the full influence list has
-been obtained. It seems to be that case that if a pagespec has any
-influences, matching any page will return at least one. So if none are
-returned, we can skip trying other pages.
-
-If the influence list does not include the page that was tried, we know
-that the pagespec does not things like `link()` and `title()`, that are
-influenced by the page's own content. So it *might* be safe to not try
-matching any more pages in this case too. I think it would work for all
-current pagespec terms. There might be a hypothetical term where this
-optimisation doesn't work. We could add a special case to ensure it can
-work: If a term declares it is unfluenced by "", then it means it is
-always influenced by the matching page.
-
-Anyway, this seems worth doing: Add a `pagespec_match_all`, which returns a
-list of all pages in the whole wiki that match the pagespec, and also adds
-the pagespec as a dependency, and while it's at it, calculates and stores
-the influence list.
-
-It could have an optional sort parameter, and limit parameter, to control
-how many items to return and the sort order. So when inline wants to
-display the 10 newest, only the influence lists for those ten are added.
-
-If `pagespec_match_depends` can be used by all plugins, then great,
-influences are automatically calculated, no extra work needs to be done.
-
-If not, and some plugins still need to use `pagespec_match_list` or
-`pagespec_match`, and `add_depends`, then I guess that `add_depends` can do
-a slightly more expensive influence calculation.
-
-Bonus: If `add_depends` is doing an influence calculation, then I can remove
-the nasty hack it currently uses to decide if a given pagespec is safe to use
-with an existence or links dependency.
-
-Where to store the influence list? Well, it appears that we can just add
-(content) dependencies for each item on the list, to the page's
-regular list of simple dependencies. So, the data stored ends up looking
-just like what is stored today by the explicit dependency hacks. Except,
-it's calculated more smartly, and is added automatically.
-
-> I've implemented influence calculation in `add_depends`. As expected,
-> it means rather a lot more work, and makes some things much slower.
-> Optimisations next.. --[[Joey]] 
-
 #### Influence types
 
 Note that influences can also have types, same as dependency types.