comments and updates a-la-airplane

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 42d2d21c1359ed7426d886723491e2b6bacd11d0..b409008c8489f74b04c3100a12bfe03293d27632 100644 (file)
--- 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 d1337665ce3f13d5c9e6b1f35e3942a5966730a9..e34aa67e36d2814acf89ecc825978d1f33e6bf90 100644 (file)
--- 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.
 
 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.
 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.
 
 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
 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.
 
 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
 
 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 a304f3b670412b975a6636378ce9859ae154976e..94060817a099179e1625b7e6265e8716b9a3e20c 100644 (file)
--- 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.
 
 * 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.
 * 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.
 [[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]]