Open teh-cmc opened 1 year ago
With https://github.com/rerun-io/rerun/pull/6951 merged, the Rerun viewer window/session model is now somewhat consistent.
--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.
(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 tolocalhost: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.