comments and updates a-la-airplane

3 files changed, 52 insertions, 4 deletions

diff --git a/doc/todo/Automatic_aggregate_setup_from_wikilist_in_Debian_package_.mdwn b/doc/todo/Automatic_aggregate_setup_from_wikilist_in_Debian_package_.mdwn
index 42d2d21c1..b409008c8 100644
--- a/doc/todo/Automatic_aggregate_setup_from_wikilist_in_Debian_package_.mdwn
+++ b/doc/todo/Automatic_aggregate_setup_from_wikilist_in_Debian_package_.mdwn
@@ -1 +1,29 @@
-ikiwiki could have an option to process /etc/ikiwiki/wikilist and run ikiwiki in aggregate mode for all wikis that need it.  The Debian package could then include an optional cron job to automatically handle aggregation.
\ No newline at end of file
+ikiwiki could have an option to process /etc/ikiwiki/wikilist and run ikiwiki
+in aggregate mode for all wikis that need it.  The Debian package could then
+include an optional cron job to automatically handle aggregation.
+
+> You can actually use ikiwiki-mass-rebuild for this. Just pass --aggregate
+> --refresh to it. (The program could have a clearer name, perhaps I should
+> rename it to mass-ikiwiki? ikiwiki-map? ikiwiki-all? ...)
+> 
+> A cron job like the one
+> you suggest could also handle cases when plugins call for a page
+> to be rebuilt. For example, a calendar plugin could use this to refresh a
+> calendar daily.
+> 
+> I do worry that such a cron job would produce more load than might be optimal.
+> If you have one wiki that never needs to updated,
+> another that might want to update daily, and a third that wants to update
+> every 15 minutes for aggregation, updating all three every 15 minutes wastes
+> a bit of CPU time. Two cron jobs seem like a better fit
+> in this situation, rather than a one size fits all master cron job. But it
+> would be fine adding a cron job as an example, at least.
+> 
+> Another problem is that ikiwiki --aggregate will fail on any wikis that don't
+> have the aggregate plugin enabled. This is really a problem with the plugin's
+> special-casey approach of adding a new flag. This could be fixed by adding
+> a more general syntax like "--set aggregate=1". (done)
+> 
+> Sorry for making this sound so complex, it's a good idea, but I'm on an
+> airplane and have nothing good to do except blather on here, and read
+> haskell tutorials. ;-) --[[Joey]]
diff --git a/doc/todo/parse_debian_packages.mdwn b/doc/todo/parse_debian_packages.mdwn
index d1337665c..e34aa67e3 100644
--- a/doc/todo/parse_debian_packages.mdwn
+++ b/doc/todo/parse_debian_packages.mdwn
@@ -8,6 +8,11 @@ a helpful index page to a small repository, listing all the
 packages, and possibly their descriptions as well, with links to
 download them or their sources.
 
+> It's a good idea, I think there are probably several ways to approach it
+> that would all yeild good, though differing results. Maybe with
+> something like this I'd actually get around to posting ikiwiki debs to
+> the repo. ;-) --[[Joey]]
+
 I think this is easily possible (and I might be able to work on
 it myself, though Perl is not my strong suit). The trickiest
 part is probably figuring out how and when to parse the packages.
@@ -18,6 +23,15 @@ reprepro/debarchiver/etc.). Or, the packages could be kept
 separate, with only a link given to the plugin, though changes
 would then not be picked up until the ikiwiki is recompiled.
 
+
+> This could be done by adding a hook to reprepro/whatever that calls
+> ikiwiki --refresh at the end of updating a repo. (I don't
+> remember if reprepro has such hooks; mini-dinstall certianly does.)
+> 
+> For ikiwiki to notice that the Packages file outside its tree has
+> changed and things need to be updated, a `needsbuild` hook could be
+> used. This seems very doable.
+
 Perhaps a better (though infinitely more complicated) solution
 would be to include the reprepro/debarchiver functionality in
 ikiwiki. Packages could be posted, like blog entries, and tagged
@@ -25,7 +39,12 @@ with the target distribution (sid/lenny/etc.). Then compiling
 ikiwiki would generate the needed Packages/Release files
 automatically.
 
+> I like the idea of
+> using packages as "source" and spitting out apt repos, though I'd not
+> want to use it for a big repo, and I'd ideally want to keep the packages
+> in a different svn repo, pulled in via svn:externals.
+
 Just some thoughts I had, hope it's not too crazy.<br>
 --Cameron
 
-[[tag wishlist]]
\ No newline at end of file
+[[tag wishlist]]
diff --git a/doc/todo/plugin_dependency_calulation.mdwn b/doc/todo/plugin_dependency_calulation.mdwn
index a304f3b67..94060817a 100644
--- a/doc/todo/plugin_dependency_calulation.mdwn
+++ b/doc/todo/plugin_dependency_calulation.mdwn
@@ -3,8 +3,6 @@ on its own:
 
 * Use of a version plugin should only make the page rebuild when it's built
   with a new version of ikiwiki.
-* The [[plugins/sidebar]] plugin should make any page get rebuilt if a
-  sidebar is created "closer" to it than the current sidebar.
 * Some plugin might want to _always_ rebuild the page that uses it.
 * If backlinks were turned into a plugin, it would need to make a page
   rebuild when its backlinks changed.
@@ -21,3 +19,6 @@ It also suggests that plugins will want to examine pages and/or
 [[store_data|plugin_data_storage]] about them to use in the dependency
 calculations. For example, the version plugin would need to store info
 about what pages use it.
+
+> I fixed this without realizing it when I added the needsbuild hook!
+> --[[Joey]]