diff options
author | http://smcv.pseudorandom.co.uk/ <smcv@web> | 2010-11-15 11:14:21 +0000 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2010-11-15 11:14:21 +0000 |
commit | 5ecba3b05d66bb58dc48a9027838e8b0bcbc0db9 (patch) | |
tree | c6e87ca43cd2415eeb034fa34382db85b9678ca7 | |
parent | 85ee24a9e53aec7d70bb4fb758428e59ea76e853 (diff) | |
download | ikiwiki-5ecba3b05d66bb58dc48a9027838e8b0bcbc0db9.tar ikiwiki-5ecba3b05d66bb58dc48a9027838e8b0bcbc0db9.tar.gz |
more discussion
-rw-r--r-- | doc/todo/transient_in-memory_pages.mdwn | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/doc/todo/transient_in-memory_pages.mdwn b/doc/todo/transient_in-memory_pages.mdwn index 816e95c38..edf056e4a 100644 --- a/doc/todo/transient_in-memory_pages.mdwn +++ b/doc/todo/transient_in-memory_pages.mdwn @@ -46,3 +46,21 @@ Refinements that could be made if this approach seems reasonable: >> The `.ikiwiki/transient` would suit this, but instead of saying "tag_underlay" or "autoindex_underlay" have "use_transient_underlay" or something like that? >> Or to make it more flexible, have just one option "transient_underlay" which is set to an absolute path, and if it is set, then one is using a transient-underlay. >> --[[KathrynAndersen]] + +>>> What I had in mind was more like `tag_autocreate_transient => 1` or +>>> `autoindex_transient => 1`; you might conceivably want tags to be +>>> checked in but autoindices to be transient, and it's fine for each +>>> plugin to make its own decision. Going from that to one boolean +>>> (or just always-transient if people don't think that's too +>>> astonishing) would be trivial, though. +>>> +>>> I don't think relocating the transient underlay really makes sense, +>>> except for prototyping: you only want one, and `.ikiwiki` is as good +>>> a place as any (ikiwiki already needs to be able to write there). +>>> +>>> For [[plugins/contrib/album]] I think I'd just make the photo viewer +>>> pages always-transient - you can always make a transient page +>>> permanent by editing it, after all. +>>> +>>> Do you think this approach has enough potential that I should +>>> continue to hack on it? Any thoughts on the implementation? --[[smcv]] |