Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

master
Joey Hess 2010-12-28 13:51:12 -04:00
commit 2de20bf48b
3 changed files with 151 additions and 47 deletions

View File

@ -1,9 +1,35 @@
*For discussion and the branch please see [[todo/transient pages]]. If this
plugin is merged, this page can be renamed to act as its documentation. --[[smcv]]*
[[!template id=plugin name=transient author="[[Simon_McVittie|smcv]]"]] [[!template id=plugin name=transient author="[[Simon_McVittie|smcv]]"]]
[[!template id=gitbranch branch=smcv/ready/transient author="[[Simon_McVittie|smcv]]"]]
[[!tag type/special-purpose]] [[!tag type/special-purpose]]
The `transient` plugin is an implementation of [[todo/transient pages]] The `transient` plugin adds an underlay in `.ikiwiki/transient`, which is
in an underlay. It's mostly useful as something other plugins can depend on; intended for pages that are automatically created and should not be committed
[[plugins/contrib/album]] puts photo-album "viewer" pages there, to the [[RCS]]. It works in the same way as the [[basewiki]] and the underlays
and the versions of [[plugins/autoindex]] and [[plugins/tag]] on the set up by the [[plugins/underlay]] plugin, so if a page in the transient
same branch optionally put their auto-generated pages there. underlay is edited via the web, the edited version is committed to the RCS
as usual. Unlike other underlays, if a page in the transient underlay is
superseded by an edited version in the RCS, the old transient version
is deleted automatically.
This plugin is mostly useful as something that other plugins can depend on:
* [[plugins/contrib/album]] always writes photo-album "viewer" pages to the
transient underlay
Likely future users of this plugin (the appropriate branches need to be
merged first):
* with a patch (which exists but hasn't yet been tested), [[plugins/aggregate]]
always writes aggregated posts into the transient underlay
* with a patch, [[plugins/autoindex]] can be configured to auto-create missing
pages that have a [[ikiwiki/subpage]] or an [[plugins/attachment]], but not
commit them, in which case they go in the transient underlay
* [[plugins/comments]] can be configured to not commit comments: if so, it
should probably put them in the transient underlay
* with a patch, [[plugins/recentchanges]] always writes new changes into the
transient underlay
* with a patch, [[plugins/tag]] can be configured to auto-create missing
tag pages but not commit them, in which case they go in the transient
underlay

View File

@ -15,6 +15,8 @@ quite, entirely unlike". I tried digging through the git history for the
reasoning behind the autofile and autoindex implementations, but now I'm reasoning behind the autofile and autoindex implementations, but now I'm
mostly confused. mostly confused.
## autofile
The autofile machinery records a list of every file that has ever been proposed The autofile machinery records a list of every file that has ever been proposed
as an autofile: for instance, the tag plugin has a list of every tag that as an autofile: for instance, the tag plugin has a list of every tag that
has ever been named in a \[[!tag]] or \[[!taglink]], even if no file was has ever been named in a \[[!tag]] or \[[!taglink]], even if no file was
@ -23,11 +25,76 @@ already exist (or whatever) are deferred until after this list has been
updated, and files in this list are never auto-created again unless the wiki updated, and files in this list are never auto-created again unless the wiki
is rebuilt. is rebuilt.
This avoids re-creating the tag `create-del` in this situation, which is
the third one that I noted on
[[todo/auto-create tag pages according to a template]]:
* create tags/create-del manually
* tag a page as create-del
* delete tags/create-del
and also avoids re-creating `auto-del` in this similar situation (which I
think is probably the most important one to get right):
* tag a page as auto-del, which is created automatically
* delete tags/auto-del
I think both of these are desirable.
However, this infrastructure also results in the tag page not being
re-created in either of these situations (the first and second that I noted
on the other page):
* tag a page as auto-del-create-del, which is created automatically
* delete tags/auto-del-create-del
* create tags/auto-del-create-del manually
* delete tags/auto-del-create-del again
or
* create tags/create-del-auto
* delete tags/create-del-auto
* tag a page as create-del-auto
I'm less sure that these shouldn't create the tag page: we deleted the
manually-created version, but that doesn't necessarily mean we don't want
*something* to exist.
## autoindex
The autoindex machinery records a more complex set. Items are added to the The autoindex machinery records a more complex set. Items are added to the
set when they are deleted, but would otherwise have been added as an autoindex set when they are deleted, but would otherwise have been added as an autoindex
(don't exist, do have children (by which I mean subpages or attachments), (don't exist, do have children (by which I mean subpages or attachments),
and are a directory in the srcdir). They're removed if this particular run and are a directory in the srcdir). They're removed if this particular run
wouldn't have added them as an autoindex (they exist, or don't have children). wouldn't have added them as an autoindex (they exist, or don't have children).
Still researching why there's this difference, and whether one or the other Here's what happens in situations mirroring those above.
would be better for all cases...
The "create-del" case still doesn't create the page:
* create create-del manually
* create create-del/child
* delete create-del
* it's added to `%deleted` and not re-created
Neither does the "auto-del" case:
* create auto-del/child, resulting in auto-del being created automatically
* delete auto-del
* it's added to `%deleted` and not re-created
However, unlike the generic autofile infrastructure, `autoindex` forgets
that it shouldn't re-create the deleted page in the latter two situations:
* create auto-del-create-del/child, resulting in auto-del-create-del being
created automatically
* delete auto-del-create-del; it's added to `%deleted` and not re-created
* create auto-del-create-del manually; it's removed from `%deleted`
* delete auto-del-create-del again (it's re-created)
and
* create create-del-auto
* delete create-del-auto; it's not added to `%deleted` because there's no
child that would cause it to exist
* create create-del-auto/child

View File

@ -21,8 +21,9 @@ It could also be used for an [[todo/alias_directive]].
-------------------------- --------------------------
[[!template id=gitbranch branch=smcv/transient-only author="[[smcv]]"]] [[!template id=gitbranch branch=smcv/ready/transient author="[[smcv]]"]]
[[!template id=gitbranch branch=smcv/transient-recentchanges author="[[smcv]]"]] [[!template id=gitbranch branch=smcv/ready/transient-recentchanges author="[[smcv]]"]]
[[!template id=gitbranch branch=smcv/ready/transient-tag author="[[smcv]]"]]
[[!tag patch]] [[!tag patch]]
I think this branch is now enough to be useful. It adds the following: I think this branch is now enough to be useful. It adds the following:
@ -32,11 +33,11 @@ as an underlay. I'm not sure whether this should be a plugin or core, so
I erred on the side of more plugins; I think it's "on the edge of the core", I erred on the side of more plugins; I think it's "on the edge of the core",
like goto. like goto.
Pages with the default extension in the transient underlay are automatically Pages in the transient underlay are automatically
deleted if a page of the same name is created in the srcdir (or an underlay deleted if a page of the same name is created in the srcdir (or an underlay
closer to the srcdir in stacking order). closer to the srcdir in stacking order).
With the additional `transient-tag` branch, With the additional `ready/transient-tag` branch,
`tag` enables `transient`, and if `tag_autocreate_commit` is set to 0 `tag` enables `transient`, and if `tag_autocreate_commit` is set to 0
(default 1), autocreated tags are written to the transient underlay. (default 1), autocreated tags are written to the transient underlay.
There is a regression test. There is a regression test.
@ -44,7 +45,9 @@ There is a regression test.
With the additional `transient-autoindex` branch, With the additional `transient-autoindex` branch,
`autoindex` uses autofiles. It also enables `transient`, and if `autoindex` uses autofiles. It also enables `transient`, and if
`autoindex_commit` is set to 0 (default 1), autoindexes are written to `autoindex_commit` is set to 0 (default 1), autoindexes are written to
the transient underlay. There is a regression test. the transient underlay. There is a regression test. However, this branch
is blocked by working out what the desired behaviour is, on
[[todo/autoindex_should_use_add__95__autofile]].
> I wonder why this needs to be configurable? I suppose that gets back to > I wonder why this needs to be configurable? I suppose that gets back to
> whether it makes sense to check these files in or not. The benefits of > whether it makes sense to check these files in or not. The benefits of
@ -67,9 +70,11 @@ the transient underlay. There is a regression test.
> commit clutter is really worth it. > commit clutter is really worth it.
>> According to the last section of >> According to the last section of
>> [[todo/auto-create_tag_pages_according_to_a_template]], chrysn and >> [[todo/auto-create_tag_pages_according_to_a_template]], [[chrysn]] and
>> Eric both feel rather strongly that it should be possible to >> Eric both feel rather strongly that it should be possible to
>> not commit any tags. I made it configurable because, as you point out, >> not commit any tags; in [[plugins/autoindex/discussion]],
>> lollipopman and [[JoeRayhawk]] both requested the same for autoindex.
>> I made it configurable because, as you point out,
>> there are also reasons why it makes sense to check these >> there are also reasons why it makes sense to check these
>> automatically-created files in. I'm neutral on this, personally. >> automatically-created files in. I'm neutral on this, personally.
>> >>
@ -95,8 +100,8 @@ the transient underlay. There is a regression test.
autoindex ignores pages in the transient underlay when deciding whether autoindex ignores pages in the transient underlay when deciding whether
to generate an index. to generate an index.
With the additional `transient-recentchanges` branch, new recent changes With the additional `ready/transient-recentchanges` branch, new recent
go in the transient underlay; I tested this manually. changes go in the transient underlay; I tested this manually.
Not done yet (in that branch, at least): Not done yet (in that branch, at least):
@ -130,51 +135,57 @@ Not done yet (in that branch, at least):
>> Here are some other things I'd like to think about first: --[[Joey]] >> Here are some other things I'd like to think about first: --[[Joey]]
>> >>
>> * There's a FIXME in autoindex. >> * There's a FIXME in autoindex.
>>
>> > Right, the extra logic for preventing autoindex pages from being >> > Right, the extra logic for preventing autoindex pages from being
>> > re-created. This is taking a while, so I'm going to leave out the >> > re-created. This is taking a while, so I'm going to leave out the
>>>> autoindex part for the moment. The FIXME is only relevant >> > autoindex part for the moment. The FIXME is only relevant
>>>> because I tried to solve >> > because I tried to solve
>>>> [[todo/autoindex should use add__95__autofile]] first, but >> > [[todo/autoindex should use add__95__autofile]] first, but
>>>> strictly speaking, that's an orthogonal change. --s >> > strictly speaking, that's an orthogonal change. --s
>> * Suggest making recentchanges unlink the transient page >> * Suggest making recentchanges unlink the transient page
>> first, and only unlink from the old location if it wasn't >> first, and only unlink from the old location if it wasn't
>> in the transient location. Ok, it only saves 1 syscall :) >> in the transient location. Ok, it only saves 1 syscall :)
>>
>> > Is an unlink() really that expensive? But, OK, fixed in the >> > Is an unlink() really that expensive? But, OK, fixed in the
>>> `transient-recentchanges` branch. --s >> > `ready/transient-recentchanges` branch. --s
>> * Similarly it's a bit worrying for performance that it >> * Similarly it's a bit worrying for performance that it
>> needs to pull in and use `Cwd` on every ikiwiki startup now. >> needs to pull in and use `Cwd` on every ikiwiki startup now.
>> I really don't see the need; `wikistatedir` should >> I really don't see the need; `wikistatedir` should
>> mostly be absolute, and ikiwiki should not chdir in ways >> mostly be absolute, and ikiwiki should not chdir in ways
>> that break it anyway. >> that break it anyway.
>>
>> > The reason to make it absolute is that relative underlays >> > The reason to make it absolute is that relative underlays
>> > are interpreted as relative to the base underlay directory, >> > are interpreted as relative to the base underlay directory,
>>> not the cwd. >> > not the cwd, by `add_underlay`.
>> > >> >
>>> The updated `transient-only` branch only loads `Cwd` if >> > The updated `ready/transient-only` branch only loads `Cwd` if
>> > the path is relative; an extra commit on branch >> > the path is relative; an extra commit on branch
>> > `smcv/transient-relative` goes behind `add_underlay`'s >> > `smcv/transient-relative` goes behind `add_underlay`'s
>> > back to allow use of a cwd-relative underlay. Which direction >> > back to allow use of a cwd-relative underlay. Which direction
>>> would you prefer? --s >> > would you prefer?
>> >
>> > I note in passing that [[plugins/autoindex]] and `IkiWiki::Render`
>> > both need to use `Cwd` and `File::Find` on every refresh, so
>> > there's only any point in avoiding `Cwd` for runs that don't
>> > actually refresh, like simple uses of the CGI. --s
>> * Unsure about the use of `default_pageext` in the `change` >> * Unsure about the use of `default_pageext` in the `change`
>> hook. Is everything in the transientdir really going >> hook. Is everything in the transientdir really going
>> to use that pageext? Would it be better to look up the >> to use that pageext? Would it be better to look up the
>> complete source filename? >> complete source filename?
>>
>> > I've updated `ready/transient` to do a more thorough GC by
>> > using File::Find on the transient directory. This does
>> > require `File::Find` and `Cwd`, but only when pages change,
>> > and `refresh` loads both of those in that situation anyway.
>> >
>> > At the moment everything in the transientdir will either >> > At the moment everything in the transientdir will either
>> > have the `default_pageext` or be internal, although I >> > have the `default_pageext` or be internal, although I
>> > did wonder whether to make [[plugins/contrib/album]] >> > did wonder whether to make [[plugins/contrib/album]]
>> > viewer pages optionally be `html`, for better performance >> > viewer pages optionally be `html`, for better performance
>>> when there's a very large number of photos. >> > when there's a very large number of photos. --s
>>>
>>> A more thorough garbage-collection mechanism would be to
>>> use File::Find on the transient directory; I'll get there
>>> eventually. --s
-------------------------- --------------------------