thoughts

diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn
index 0503b47afd652a45543185c8f2a212e9a18f7c86..9d649e1e08d1db7aa8f87aeac7c275bd3c29b546 100644 (file)
--- a/doc/todo/dependency_types.mdwn
+++ b/doc/todo/dependency_types.mdwn
@@ -170,6 +170,11 @@ I added an "add_depends_spec()" function that adds a dependency on the pagespec
 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.
 
 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
 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 @@ after `test_page`.  `new_page` will not match the spec.  Now we'll delete and th
 `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?
 
 `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
 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,6 +227,19 @@ sigh.
 
 -- [[Will]]
 
 
 -- [[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
 ---- 
 
 ### Link dependencies


@@ -259,9 +282,22 @@ we grew the complication of `depends_simple`.
 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.
 
 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
 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.