So I figure I should post a new one of these.
But let's start with an evaluation of roadmap 1:
Zeitgeist
Less has happened than I would have wished. I've fixed a significant
graphical glitch and tinkered around a bit. I've also implemented a
suggestion from CamDawg that allows for oggdec, et al. to be
distributed with WeiDU/Zeitgeist instead of as part of the mod
itself. There's also the addition of archives; see below.
Replacement for READLN
This has been postponed and folded into another of my zany
schemes. See "TP3".
Cross-platform distribution format
In October I added the ability to create and extract ZIP archives to
Zeitgeist. I choose ZIP because it's a very widely supported format
and more advanced compression algorithms and formats offer very
limited advantages over ZIP since most mods consist of text, which
compresses well regardless, and already compressed resources (images,
audio), which further compress poorly, regardless. I tested this with a
few mods and between ZIP, 7Z and TAR.XZ the biggest difference I saw
was on the order of 100 kBi.
There are still some UX concerns (notably, no prompt before
overwriting) and it's a few bits shy of a full-baked feature.
Onto the new roadmap:
Stack management is all grown up and now it's moving out
I'm working on adding stack management to Zeitgeist. The slightly
longer plan is to allow mods the possibility of pinning their WeiDU
version. Since version-pinning is incompatible with WeiDU's stack
management, this feature can only be implemented if something else
takes over the duty.
For example, suppose the mod stack looks like this:
foo - WeiDU 300
bar - WeiDU 299
baz - WeiDU 301
The listed WeiDU version (fictitious) are pinned by the respective
mod. One WeiDU cannot handle all three mods, because maybe 301 broke
something that worked in 299 and maybe 299 does not support some
feature that exists in 301, and both of these hypotheticals apply to
300.
When the user requests to uninstall bar, Zeitgeist would call on WeiDU
301 to uninstall baz, WeiDU 299 to uninstall bar and then WeiDU 301
again to reinstall baz. Each mod can be handled with its version of
WeiDU.
In stack management today, all three mods are handled by the same and
most recent locally available version of WeiDU.
I guess we'll have to wait and see what the implications of this will
be. One possibility is a new release model, but that's the stuff of
future maps of the road.
"TP3"
I posted about the idea some time ago,
here.
A config system to replace READLN would simply be an object in the
larger JSON file. This way you avoid the question of where it should
be located and what it should be called. It can be CoWed
(copy-on-write) if you want immutability. It's available to WeiDU and
other programs alike.
Pinning your mod's WeiDU version would be easy.
The install-time predicates that give non-WeiDU install drivers such a
hard time today could be simplified into predicates that are fully
knowable in advance. This would, of course, mean that some TP2
predicates that are supported today would not have "TP3" analogues,
but on the whole I think there's more to gain than there is to lose.
It should be possible to write a conversion function that takes TP2 as
input and emits "TP3".
There's possibly also some stuff about tests, the build system and the
documentation, but it's not really roadmap stuff and I'm even less
certain about when and if these things will get done.
Feel free to comment.