diff options
| -rw-r--r-- | doc/todo/Automatic_aggregate_setup_from_wikilist_in_Debian_package_.mdwn | 30 | ||||
| -rw-r--r-- | doc/todo/parse_debian_packages.mdwn | 21 | ||||
| -rw-r--r-- | doc/todo/plugin_dependency_calulation.mdwn | 5 |
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]] |