summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>2007-08-04 06:27:02 +0000
committerjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>2007-08-04 06:27:02 +0000
commitb55dfcd03d81257e4794f5f6762d27c013f8aa3d (patch)
tree2eb976bc6c4d9fdee3a2a023f554f9034cfb61f6 /doc
parentc38dd537e92ac6be58560aba292446787265a9e5 (diff)
comments and updates a-la-airplane
Diffstat (limited to 'doc')
-rw-r--r--doc/todo/Automatic_aggregate_setup_from_wikilist_in_Debian_package_.mdwn30
-rw-r--r--doc/todo/parse_debian_packages.mdwn21
-rw-r--r--doc/todo/plugin_dependency_calulation.mdwn5
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]]