clearer/simplified "application model" for the main `rerun` binary and SDK

[teh-cmc]

(Following a lengthy standup discussion)

The TL;DR is that the current "application model" for rerun (i.e. what's a client? what's a server? how can new windows be created? when are windows shared? etc) can be too limiting in some places, or inversely too liberal in others, and sometimes inconsistent and/or straight confusing in yet other places.

I've tried to summarized most of the results of these discussions below.

Native

On native, the general consensus seems to be to move towards a model where every single Rerun window is a server (always, no exception) and teach the user the simple rule "one window == one TCP port". E.g. sending data to localhost:1337 will always end up in the same window (which will be lazily created if does not exist), sending to localhost:1338 will create another one, etc.

You cannot create a server independently: it always comes with a viewer, and the lifetimes of the two are interlocked. Effectively we hide the client-server model (for now), and just communicate that one port == one window. If compiled with the web feature, we also make sure to always boot a websocket server as-well, no exception.

We make sure to provide a way so that it is easy to know all the ports and protocols that a window is listening on.

We also should have a way of loading an rrd file by sending it to a port (e.g. rerun some_file.rrd --port 1337), i.e. sending it to a specific window. Effectively, rerun some_file.rrd without a port specified would create the window for the default port if it doesn't exist, or send the data over there otherwise.

On the SDK side, we change the default behaviour of spawn_and_connect so that it always binds to an unused port if none is specified and, as such, always creates a new window by default.

Web

On the web, we do advertise the client-server model very clearly, as it is the expectation in these lands.

The web viewer always shows the URL we're connected too, and we make it clear that the user can use any websocket URL that they can find in any Rerun window.

Spawning a web server independently of anything else is not only possible, but mandatory by design.

Future work

Some possibilities that were mentionned:

• connect_or_spawn

Somewhat related to #895.

[teh-cmc]

With https://github.com/rerun-io/rerun/pull/6951 merged, the Rerun viewer window/session model is now somewhat consistent.

• Every Rerun viewer session now corresponds to a Rerun TCP server.
• You cannot start the Rerun viewer without starting a TCP server.
• The only way to have more than one Rerun window is to have more than one TCP server, which means using the --port flag.

# starts a new viewer, listening for TCP connections on :9876
rerun &

# does nothing, there's already a viewer session running at that address
rerun &

# does nothing, there's already a viewer session running at that address
rerun --port 9876 &

# logs the image file to the existing viewer running on :9876
rerun image.jpg

# logs the image file to the existing viewer running on :9876
rerun --port 9876 image.jpg

# starts a new viewer, listening for TCP connections on :6789, and logs the image data to it
rerun --port 6789 image.jpg

# does nothing, there's already a viewer session running at that address
rerun --port 6789 &

# logs the image file to the existing viewer running on :6789
rerun --port 6789 image.jpg &

Now what's left is to document the application model in a page somewhere, explaining the general dataflow and showing a nice diagram of everything.