thoughts on some future stuff

master
joey 2006-08-18 04:12:29 +00:00
parent c6ee9cbf45
commit 9adb841c92
2 changed files with 38 additions and 3 deletions

View File

@ -2,9 +2,21 @@
times in worst case (8 times if there's an rss feed).
The issue is that rendering a page is used to gather info like the links
on the page that can effect rendering other pages. So it needs a
multi-pass system. But rendering the whole page in each pass is rather
obscene.
on the page (and other stuff) that can effect rendering other pages. So it
needs a multi-pass system. But rendering the whole page in each pass is
rather obscene.
It would be better to have the first pass be a data gathering pass. Such
a pass would still need to load and parse the page contents etc, but
wouldn't need to generate html or write anything to disk.
One problem with this idea is that it could turn into 2x the work in
cases where ikiwiki currently efficiently renders a page just once. And
caching between the passes to avoid that wouldn't do good things to the
memory footprint.
Might be best to just do a partial first pass, getting eg, the page links
up-to-date, and then multiple, but generally fewer, rendering passes.
* Don't render blog archive pages unless a page is added/removed. Just
changing a page doesn't affect the archives as they show only the title.

View File

@ -0,0 +1,23 @@
A few plugins need more complex dependency calculations than ikiwiki can do
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.
These suggest there should be a way for plugins to have hooks that tweak
the list of pages to rebuild.
Which in turn suggests that there should *be* a list of pages to rebuild;
currently there's not, and the best such an interface could do would be to
rebuild the pages even if they were already going to be rebuilt for some
other reason. (See [[optimisation]].)
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.