MWS is a major change in how wikis are stored - SQLite vs Filesystem
Does that qualify for a major release change of TiddlyWiki5 - to TiddlyWiki6?
I haven’t spent the time I want to with MWS. So I don’t understand some basics.
Is this to be a replacement for the existing Node version, or will it be an optional configuration/set of commands? Many of my normal workflows involve creating large lists of tiddler files or modifying existing ones, all from the command line or from Node scripts. If MWS made that harder to do, I would consider suggesting it should be a major version.
But TW has clearly shied away from releasing major versions. TW5 is, what, twelve years old? If the new version does not support common-enough use-cases that the current version does, I guess we would have to go that route. I’d also be disappointed.
Looking in still being relatively outside the dev process (but MWS being the future I’m most interested in), my basic thought is “major versions should be for incompatible syntax changes”. Minor version could makes sense though - 5.4.0?
(tangent: Is the SQLite a storage requirement though? The impression I got from https://mws.tiddlywiki.com/static/MWS%20and%20SQLite.html is that sqlite replaces an internal javascript DB engine - and this line: “One particular misconception to avoid is the idea that SQLite replaces the folders of .tid files that characterise the Node.js configuration of TiddlyWiki. These are separate components with a different purpose.” So I’d think @Scott_Sauyet’s use-case (and mine - I use .tid files and a git backend to store history) would continue? Or is that page now out of date?
I certainly hope that is still the case, because if the nodejs is planned to be replaced by MWS, then I’m out. I’ll just have to stick with the last version of the nodejs tiddlywiki that still uses separate .tid files. I have no desire to have my tiddlers trapped in a SQLite dataset that can become corrupted. There was talk about backup systems that would take care of that, but no thanks. Individual files are the only way I can be sure each and every tiddler is under proper version control, so I can see the individual changes and swap out .tid files as needed. I just sure hope the plan is simply for it to be an option, but not a replacement. That is exactly why I do not use the standalone tiddlywiki .html file, as that is a single point of failure.
MWS is a plugin. It is not intended to replace existing mechanisms. It should complement them.
6 Likes
I think MWS would break the single-file Theme of TiddlyWiki, while I think in the future a lot of users will drop things like node.js (default setup) and webdav in favor of an easier layout like MWS, for simple offline and Compatability MWS may hinder some use cases, case an point Welfords TWexe requires TiddlyWiki to run as an HTA File, since MWS is a hosted system vs local this would be near-impossible. Just my thoughts
The plan for MWS is to be a completely separate system that ties into as many parts of TiddlyWiki as possible to enhance them. It’s focused on a fairly common use-case that so far hasn’t received as much attention.
The file system adapter (aka FSA) is just a thin wrapper around the TiddlyWiki store that saves tiddlers back to the file system in a way that is compatible with the loading of plugin and edition folders.
MWS is just another slightly bigger wrapper around TiddlyWiki that allows it to be stored in a database instead of on the file system. It has wide implications for online and NAS based wikis.
FSA and the core tiddler system aren’t going anywhere, since in Javascript a tiddler is just a JSON object with a bunch of fields, and MWS and FSA just take that object and store it in different ways. FSA certainly won’t be removed in favor of MWS.
You can’t use both at the same time for the same wiki (although that might be a good idea), but nothing is preventing you from using them separately.
MWS replaces the --mws-listen command specifically, and it stores tiddlers on the server in a way that is incompatible with existing tooling. However, since tiddlers are just a collection of string fields, there’s no reason we couldn’t add a command to export a particular wiki to the file system. Currently there is an archive dump command which dumps the entire database into json files, and those could be used to preloadTiddlers, if nothing else.
I guess it would be useful to export a single wiki as a json file in a way that would at least be compatible with loading into the preloadTiddlers array. I don’t know the ins and outs of tiddler field mechanics beyond that but I have gotten the picture that it’s all pretty custom depending on exactly what plugins are loaded.
Feel free to open an issue on Github if you run into any issues with this.