From 2ba8bd386142e7f3c0fb03c86eb90eb3885aabd2 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 9 Oct 2009 17:19:07 -0400 Subject: remove highlevel influence calculation stuff 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 | 51 ------------------------------------------ 1 file changed, 51 deletions(-) (limited to 'doc') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 6ca06fdab..e95965c33 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -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. -- cgit v1.2.3