47 lines
2.2 KiB
Markdown
47 lines
2.2 KiB
Markdown
Maybe this is obvious, but the config variable lives in the IkiWiki module, and one probably
|
|
wants to call defaultconfig for most applications.
|
|
<pre>
|
|
%IkiWiki::config=IkiWiki::defaultconfig();
|
|
IkiWiki::Setup::load($config_file);
|
|
print join(",",keys %IkiWiki::config);
|
|
</pre>
|
|
|
|
[[DavidBremner]]
|
|
|
|
I'm a little concerned about one aspect of the `%wikistate` variable that was just introduced.
|
|
I think global state for each plugin is a fine idea, but I worry about making it persist across
|
|
rebuilds. (And by rebuild, I assume we're talking about the `--rebuild` option.)
|
|
|
|
My reasoning is that a 'rebuild' should be similar to checking out a new copy of the wiki
|
|
and building. Another way of saying this is that all permanent state should be in the RCS.
|
|
It is great that there is temporary state stored in other places - I think of it as indexing
|
|
and caching. I'm worried that with the persistence, plugin writers will start putting data
|
|
there that isn't backed by the RCS and that will break IkiWiki's great abilities as a
|
|
distributed wiki.
|
|
|
|
[[Will]]
|
|
|
|
> Well, if you look at state that already persists across rebuilds, we have
|
|
> pagectime, which can be extracted from RCS only very slowly in many
|
|
> cases. There's also the separate state stored by the aggregate plugin,
|
|
> which is indeed independant of the RCS, and can in some cases not be
|
|
> replecated by rebuilding a different checkout (if the data is gone from
|
|
> the feeds). Then there's the session cookie database, and the user
|
|
> database, which started out with a lot of local state, has been
|
|
> whittled down by removing admin prefs and subscriptions, but still has
|
|
> important state including password hashes.
|
|
>
|
|
> So while I take your point about the potential for abuse,
|
|
> there's certianly legitimate reasons to need to store data across
|
|
> rebuilds. And plugins have always been able to drop their own files in
|
|
> wikistatedir as aggregate does and have it persist, so the abuse
|
|
> potential has always been there, the barrier has been lowered only
|
|
> slightly.
|
|
>
|
|
> OTOH, if something can be added to the documentation that encourages
|
|
> good behavior, that'd be a good thing ... --[[Joey]]
|
|
|
|
---
|
|
|
|
I would find this page clearer split up into sub-pages. Does anyone agree/disagree? -- [[JonDowland]]
|