Proposal: Semantics-level runtime ReadOnly mode for CLI commands

[shayne-snap]

I’m still learning the runtime internals, so this is a semantics-level proposal for discussion (NOT an implementation proposal yet).

Why this might help

• Better concurrency expectations for CLI usage.

Current situation (as I understand it)

Right now, BoxLite is no daemon required. Multiple boxlite CLI processes against the same BOXLITE_HOME do not compose well.

Each CLI command creates its own runtime instance, and that runtime takes an exclusive home-level lock for the process lifetime. As a result, a second command started at the same time typically fails immediately instead of waiting or coexisting.

user case: I'm building an Electron App to test the boundaries of BoxLite. e.g. The Electron App process is holding the runtime lock, I wanna execute boxlite list -all and boxlite images to check the status of images and boxes.

Proposal (semantics only)

Introduce two runtime access modes at the command-semantics level:

• RuntimeMode::ReadOnly
• RuntimeMode::ReadWrite

Initial command grouping proposal:

• list/images/info -> RuntimeMode::ReadOnly
• exec/run/create/start/stop/rm/pull -> RuntimeMode::ReadWrite

Expected semantics

• ReadOnly commands should be safe to run alongside ReadWrite operations when possible.
• ReadWrite commands keep full mutation authority and correctness guarantees.

This proposal only defines command intent/semantics, NOT internal locking/mechanism.

Would love to hear your thoughts on this.

[DorianZheng]

I think we need it