We should probably refactor the build script into something more
object-oriented too, since it's getting somewhat complicated. I've added
some ASCII art headers as a stop-gap for now, but a proper refactor of
that too (into a class-based system probably) is incoming I think.
The BkTree tester gave me the idea.
No longer will you have to hope that search indexing will complete in
time and adjust the maximum execution time for larger wikis..... when
that's implemented.
The shell has given me an idea.....
We could have a CLI module to Pepperminty Wiki that allow admins to run
longer-running tasks without them getting killed 1/2 way through because
of a timeout.
....I was gettign increasinly nervous about not committing these to git.
Hopefully at some point soon I'll be able to integrate the BkTree into
Pepperminty Wiki properly - but I still need to implement word removal
first before I can do that.
Also, feature-search is getting big. It's refactoring time to be sure,
but Im uncertain at this stage precisely _how_ I want to go about that.
I've got 2 ideas:
1. Refactor the engine and the storage box into separate "library
modules"
2. Refactor them into their own repository/ies or something, and include
them as extra data
3. Extend the extra data system to support local files and include them
in the main Pepperminty Wiki repository
Thought is required. If anyone actually reads this message, do get in
touch with your thoughts!