Design: Choose/Consolidate our interface(s)

[simonvanderveldt]

(Technical) Interfaces

At the moment we use three interfaces:

• Websockets for interactive functionality
• OSC for ???
• HTTP API for the rest

It would be good to define and document which one should be used for which purpose and use them accordingly.

User (facing) interfaces

We currently don't make the functionality that is offered via the above mentioned interfaces available everywhere. For example the fetch functionality is available only through the REPL but not via a CLI command whereas the "install script" functionality is available via the CLI and a HTTP command but not via the REPL. I think we have three places where we want to expose functionality to the user:

• Command-line
• REPL
• maiden (i.e. buttons/actions done from maiden)

Is this list complete? If so it would be good to think about if we want all functionality available in all three of those or if some functionality should be made available only in a subset.

Which functionality?

This leads us to which functionality do we have/need? I've made a start of an overview based on the resources we have and which actions we want to be able take on these resources below. There's probably stuff missing:

• system
  • actions:
  • restart?
  • shutdown
  • get logs?
• norns stack
  • this consists of multiple components:
  • crone
  • jack
  • maiden
  • matron
  • sclang
  • watcher actions:
  • start?
  • stop?
  • restart
• engines:
  • consists of:
  • sclang
  • actions:
  • start?
  • stop?
  • restart
• catalog:
  • actions:
  • add?
  • update
• scripts:
  • actions:
  • install
  • uninstall
  • update?
  • run
• psets?
  • actions:
  • rename?
  • delete?
• crow?

This was triggered by the discussions in https://github.com/monome/norns/pull/1276 and https://github.com/monome/maiden/issues/192

[simonvanderveldt]

Suggestion would be:

• All interactive stuff happens in a REPL which uses websockets
• All other actions happen either in maiden or using the CLI both of which would use the same HTTP API

Some questions:

• Do we want to allow some actions in the REPL? If so which ones? I think this would mean the REPL would need to do both websockets and HTTP
• What do we want/need to use OSC for?

[ngwese]

I think a statement of problem would help ground subsequent discussion.

• Who is consolidation aimed at?
• What would consolidation enable?
• What risks are present if consolidation isn't done?

(to be clear I'm not advocating against this, just hoping the goal is clear since this touches many different pieces of the system)

[tehn]

i think this is coming up for two reasons:

• norns.fetch (very recently added) should be deprecated in favor of ;install on maiden. i'm not sure there needs to be a norns function for managing scripts as such, when the HTTP interface can be used directly.
• i mentioned earlier stuffing more functionality into watcher but i rescind that proposal given how much maiden already accomplishes very well.

re: user cases

• ;install completes what i see as the needs of the community regarding a robust sharing mechanism

re: technical interfaces

• for restarts/etc i would say systemd is the consolidated interface
• for remote management of scripts outside of maiden, HTTP is great
• OSC is pretty irrelevant here, that's used as an IPC between matron and crone (and sc)
• if maiden-repl were to be upgraded, there is a clear/easy path forward for that

@simonvanderveldt more generally i'd say the missing link right now is log management and a workable way for people to submit/read logs. if you'd like to take this on, it's one area i think you might be familiar with. i personally don't think we need commands to do anything fancy with the logs--- if they're just processed and symlinked to dust/data/log (or something) that seems more than adequate to me. (we can create a new issue for further discussion)

[simonvanderveldt]

@ngwese This doesn't necessarily mean anything will change, although there are probably some things that should be. Also I should've probably spent more time formulating the issue, to me it's clear, but apparently it's not.

The short version is that we're (sometimes) just diving in head first coding, adding stuff here and there, which is of course not the best approach to end up with a consistent and clear result. This issue is there to figure out the basics and would probably result in some docs with guidelines about the things mentioned in the issue description for anyone working on the norns stack and maybe a small checklist for PRs to the norns stack.