urosm
/
ikiwiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

comments and updates a-la-airplane

master
joey 2007-08-04 06:27:02 +00:00
parent c38dd537e9
commit b55dfcd03d
3 changed files with 52 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
doc/todo/Automatic_aggregate_setup_from_wikilist_in_Debian_package_.mdwn
View File

@ -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.
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]]

21
doc/todo/parse_debian_packages.mdwn
View File

@ -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]]
[[tag wishlist]]

5
doc/todo/plugin_dependency_calulation.mdwn
View File

@ -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]]