Musings on "single operator two rigs".

[aknrdureegaesr]

This is an answer to #442 (comment) where you write

[not1mm] will eventually support so2r, and would need to have more than one main window active. Writes to the database are atomic so there should be no corruption to the database.

I expect #442 to be closed soon-ish and this topic to be much more long-lived, so I decided to open a new issue solely for discussion.

This is some ideas I have, or design decisions I would seriously consider if I were you.

But I'm not you. Kindly use of the following material whatever you find helpful, and unceremoniously dump everything else into the trash.

Avoid special so2r code

"Single operator two rigs" so2r is a rare use case as not many people do it. So any code that is special for this will not see a lot of execution and thus will be difficult to iron out. So I'd try to avoid writing such code.

Momr should be first!

I personally very much look forward to "multi operator multi rigs" momr. Once that works smoothly, we can finally ditch Windows and the n1mm+ logger and use Linux for our yearly WAG weekend. Yeah!

In general, the demand for momr will be more common than that for so2r. So momr should be developed first.

Use momr facilities for so2r

If you agree so far, the idea becomes pretty obvious: Can we use momr to cover so2r ground?

For so2r, I would try to run two instances of not1mm on the same computer with the same user, but with different XDG_DATA_HOME and XDG_CONFIG_HOME directories.

Those two separate instances of not1mm can that talk to each other via localhost networking.

Fine print:

• That suggests the lockfile of Catch second program invocation. #442 should live in XDG_DATA_HOME. Imho, that's a pretty obvious choice anyway.
• You should not simply use whatever socket.gethostname returns as a differentiator of several instances that talk over the network.
  • This should instead be configurable.
  • Across restarts, the same differentiator should be used, so it is persisted.
  • For enhanced sanity, there should be a check that not two different instances on the same network use the same differentiator. For that, each instance could dice out a temporary id for itself on startup and communicate that to all other instances it finds on the network, together with the persistent differentiator. Should any "same differentiator, different temporary id" be found, ring the alarm bells and do not proceed.
  • People that somehow manage to run not1mm under Docker or similar containerized systems (that may or may not provide a decent hostname) will also love it if this is configurable.

Problem to ponder: An so2r operator will want to switch from one not1mm window to the other easily and quickly. Can this be done with regular window manager functionality?

[aknrdureegaesr]

An so2r operator could, of course, just use not only two rigs, but also two computers, two keyboards, two displays. Not sure what these people find convenient.

[mbridak]

I'm moving this to the discussions section.