[MWS] How simple can we make the CLI for MWS?

#1

I want to put as much configuration as I can in the web admin UI and store it in the database instead of in a config file. Looking for opinions, feedback, or input on how simple we can make it or things you like or don’t like about various options.

Things we can’t put in the admin web UI.

  • The wiki path: You can’t store the path to the database in the database itself.
  • Private keys: The password master key and SSL certs and keys have to be controlled by the server owner.
  • Listeners: This always depends on the server environment, but we can use sane defaults like localhost and PORT env.
  • URL path prefix: Generally you won’t be changing this unless you’re already doing advanced JavaScript stuff. And it’s guaranteed to break web access if you make a mistake, requiring a CLI intervention to reverse it, so it might as well just stay in the CLI.
    • This should probably be set per listener? If you need a prefix, you probably need it because it’s behind a parent application or reverse proxy on a specific port.

All of these can be CLI options.

In “posix standard”:

mws --wiki wiki --passwordkey localpass.key \
    listen --prefix /dev --host localhost --port 8080 \
    listen --host localhost --port 8443 --key test/test.key --cert test/test.cert

This would completely replace any run file, as all other config would be administrated through the web interface. What do you all think? Is this a good idea?

Or in TiddlyWiki style, which uses -- for subcommands and then splits the options on the first = character.

mws wiki=wiki passwordkey=localpass.key \
    --listen prefix=/dev host=localhost port=8080 \
    --listen host=localhost port=8443 key=test/test.key cert=test/test.cert

Things that could go in an installer UI (and setup command)

  • Initial Database selection and setup (stored in the wiki folder)
#2

re: CLI style - I think the TW style is more intuitive overall, and matches plenty of other CLI utilities which have commands/subcommands as words, and options as -l or --long-option style (all of which makes a bit of a joke of the idea of “standard posix”)

I’m a fan of keeping the CLI to the minimum required to run, and as many options controlled within MWS as possible. On that line, couldn’t the path to key and certs be within the UI? Sure the updates to them are outside TW control, but they can still be standardised paths saved to the DB and not needing to be on the CLI?

A question (I hope this isn’t a derailing tangent) about the DB - is it absolutely required for the structure of MWS, or just a coincidence that it’s been developed in tandem with MWS? I know some folks are keen on MWS but hesitant on a binary DB, and I suspect some node users wouldn’t care less about MWS but would benefit greatly from the DB.

#3

I think everything security related should be outside the database, so we can make backups without exposing too much information about the system where the software runs on.

1 Like
#4

I personally think that every command that can be done with the UI should be doable with the CLI. — But — This probably introduces a lot of extra work.

So my suggestion is to have a configuration tiddler that can be used to “hydrate” the database at creation time, when the database is created.

The format of the config-file can be a CompoundTiddler. They have several advantages:

  • CompoundTiddlers are first class citizens
  • The configuration can be as simple or as complex as we need it
  • No bloated 3rd party library is needed to read the config
  • The advantage of a compound tiddler is, that it can contain encrypted content and plain text at the same time.

I still think, that security related configurations should be separated from plain text configs.

Just some initial thoughts.

#5

I believe you may have gotten that difference backwards. The way you describe it with subcommands as words and options as -l or --long-option is what I was referring to as POSIX standard. I’ve edited my post to better reflect this.

#6

Yes, the entire point of MWS is the DB. MWS is focused on the multi-user and multi-wiki scenario, and if we didn’t use an existing database system, we would essentially have to write our own, with proper locking (to prevent one request from writing to a tiddler while another is half way through reading a tiddler), and a mostly full blown query engine, while still making sure we support the use of actual databases for situations where file systems are ephemeral or read-only.

That being said, it’s still possible that we could support tiddler folders in some form. What use cases would you have for storing tiddlers on the file system instead of a database?

#7

This should actually be pretty simple. Since the admin UI is already designed with a standardized API which marshals requests into handler functions, it would be trivial to execute those same endpoints from the CLI. I’m planning to do this with the admin (“manager”) endpoints.

#8

That’s a good question and one I had intended to answer a day or two later after some thought, but then life, the universe, and everything distracted me. Finally remembered and circled back!

So I had been conflating a few factors in my previous thinking.

I find file-based tids valuable in my current use case for importing from various pre-TW notes (TWC, tomboy, macos Stickies, etc. Converting each to a .tid (or sometimes a .txt or .md with appopriate .meta) file and restarting node, makes import of such things easy. However, on thought, that doesn’t mean they need to stay that way - my use case only requires the import of files based tids into the DB at any time.

The other thing I rely on file based tids for is storing history via local git. I’ve got a pretty well trodden git workflow, and the git tools make inspecting history of edits reasonably trivial. (it’s pretty rare I need to do that, but I appreciate the setup when I do!). Again, this doesn’t preclude the storage as files, only that export be possible, and if MWS stored version history within it’s DB, then I may not even need to bother with that.

Part of the conflation is that I have two largely unrelated ideas for using MWS - one is my personal setups, where I’m thinking I’ll find value in the multiple wiki side of things, and is where I’m likely to want to import files. The other is a setup for an organisation, where I’ll likely only need a single wiki, but multiple-user handling will be of great value and thus storing revision history is no longer just a personal idiosyncrasy, but instead is an important audit and accountability tool.