[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.