Remove remaining mentions of rr.connect

README.md

@@ -32,9 +32,9 @@ import rerun as rr  # pip install rerun-sdk
 
 rr.init("rerun_example_app")
 
-rr.connect()  # Connect to a remote viewer
-# rr.spawn()  # Spawn a child process with a viewer and connect
+rr.spawn()  # Spawn a child process with a viewer and connect
 # rr.save("recording.rrd")  # Stream all logs to disk
+# rr.connect_grpc()  # Connect to a remote viewer
 
 # Associate subsequent data with 42 on the “frame” timeline
 rr.set_time("frame", sequence=42)

crates/top/re_sdk/src/recording_stream.rs

@@ -34,7 +34,7 @@ use crate::sink::{LogSink, MemorySinkStorage};
 /// Private environment variable meant for tests.
 ///
 /// When set, all recording streams will write to disk at the path indicated by the env-var rather
-/// than doing what they were asked to do - `connect()`, `buffered()`, even `save()` will re-use the same sink.
+/// than doing what they were asked to do - `connect_grpc()`, `buffered()`, even `save()` will re-use the same sink.
 const ENV_FORCE_SAVE: &str = "_RERUN_TEST_FORCE_SAVE";
 
 /// Returns path for force sink if private environment variable `_RERUN_TEST_FORCE_SAVE` is set

design/blueprint_store.md

@@ -33,7 +33,7 @@ part of Viewer startup. This limits blueprint control to: `rr.spawn()` (launch a
 hosted web-app), and `rr.show()` (embed a Viewer in a notebook). Additionally a blueprint file will be able to be
 provided to the Viewer via the CLI at launch, or opened via the file-menu.
 
-Blueprints will not otherwise be able to be sent via `rr.connect()`, which is reserved for only transmitting log-data to
+Blueprints will not otherwise be able to be sent via `rr.connect_grpc()`, which is reserved for only transmitting log-data to
 an existing live Viewer instance, where a relevant blueprint is assumed to be loaded.
 
 ### Blueprint APIs

docs/content/concepts/app-model.md

@@ -66,7 +66,7 @@ Deployment:
 # This will also start the gRPC server on its default port (9876, use `--port`
 # to pick another one).
 #
-# We could also have just used `spawn()` instead of `connect()` in the logging
+# We could also have just used `spawn()` instead of `connect_grpc()` in the logging
 # script above, and # we wouldn't have had to start the Native Viewer manually.
 # `spawn()` does exactly this: it fork-execs a Native Viewer in the background
 # using the first `rerun` # binary available # on your $PATH.
@@ -88,10 +88,10 @@ Dataflow:
 
 
 Reference:
-* [SDK operating modes: `connect`](../reference/sdk/operating-modes.md#connect)
-* [🐍 Python `connect`](https://ref.rerun.io/docs/python/0.19.0/common/initialization_functions/#rerun.connect)
-* [🦀 Rust `connect`](https://docs.rs/rerun/latest/rerun/struct.RecordingStreamBuilder.html#method.connect)
-* [🌊 C++ `connect`](https://ref.rerun.io/docs/cpp/stable/classrerun_1_1RecordingStream.html#aef3377ffaa2441b906d2bac94dd8fc64)
+* [SDK operating modes: `connect_grpc`](../reference/sdk/operating-modes.md#connect_grpc)
+* [🐍 Python `connect_grpc`](https://ref.rerun.io/docs/python/stable/common/initialization_functions/#rerun.connect_grpc)
+* [🦀 Rust `connect_grpc`](https://docs.rs/rerun/latest/rerun/struct.RecordingStreamBuilder.html#method.connect_grpc)
+* [🌊 C++ `connect_grpc`](https://ref.rerun.io/docs/cpp/stable/classrerun_1_1RecordingStream.html#aef3377ffaa2441b906d2bac94dd8fc64)
 
 ### Asynchronous workflow
 

docs/content/concepts/static.md

@@ -87,7 +87,7 @@ If you wanted the recording file itself to only contain a single static value, y
 
 The data store that backs the Rerun viewer natively understands these temporal/garbage-collected vs. static/overwritten semantics.
 
-If you were to log the snippet above directly to the Rerun viewer (using e.g. `rr.connect()`), you'd notice that the viewer's memory usage stays constant: the data is automatically being overwritten as new updates come in.
+If you were to log the snippet above directly to the Rerun viewer (using e.g. `rr.connect_grpc()`), you'd notice that the viewer's memory usage stays constant: the data is automatically being overwritten as new updates come in.
 For data where you don't need to keep track of historical values, this effectively to logs its new values indefinitely.
 
 In the following example, you can see our [face tracking example]() indefinitely tracking my face while maintaining constant memory usage by logging all data as static:

docs/content/getting-started/data-in/python.md

@@ -288,7 +288,7 @@ Rerun offers several solutions for such use cases.
 
 At any time, you can start a Rerun Viewer by running `rerun`. This Viewer is in fact a server that's ready to accept data over gRPC (it's listening on `0.0.0.0:9876` by default).
 
-On the logger side, simply use [`rr.connect`](https://ref.rerun.io/docs/python/stable/common/initialization_functions/#rerun.connect) instead of [`rr.spawn`](https://ref.rerun.io/docs/python/stable/common/initialization_functions/#rerun.spawn) to start sending the data over to any gRPC address.
+On the logger side, simply use [`rr.connect_grpc`](https://ref.rerun.io/docs/python/stable/common/initialization_functions/#rerun.connect_grpc) instead of [`rr.spawn`](https://ref.rerun.io/docs/python/stable/common/initialization_functions/#rerun.spawn) to start sending the data over to any gRPC address.
 
 Checkout `rerun --help` for more options.
 

docs/content/getting-started/data-out/analyze-and-send.md

@@ -32,7 +32,7 @@ rr.init(
     recording.application_id(),
     recording_id=recording.recording_id(),
 )
-rr.connect()
+rr.connect_grpc()
 ```
 
 _Note_: When automating data analysis, it is typically preferable to log the results to an distinct RRD file next to the source RRD (using `rr.save()`). In such a situation, it is also valid to use the same app ID and recording ID. This allows opening both the source and result RRDs in the viewer, which will display data from both files under the same recording.

docs/content/howto/integrations/embed-notebooks.md

@@ -24,7 +24,7 @@ This installs both [rerun-sdk](https://pypi.org/project/rerun-sdk/) and [rerun-n
 ## The APIs
 
 When using the Rerun logging APIs, by default, the logged messages are buffered in-memory until
-you send them to a sink such as via `rr.connect()` or `rr.save()`.
+you send them to a sink such as via `rr.connect_grpc()` or `rr.save()`.
 
 When using Rerun in a notebook, rather than using the other sinks, you have the option to use [`rr.notebook_show()`](https://ref.rerun.io/docs/python/stable/common/initialization_functions/#rerun.notebook_show). This method embeds the [web viewer](./embed-web.md) using the IPython `display` mechanism in the cell output, and sends the current recording data to it.
 
@@ -58,7 +58,7 @@ rr.notebook_show()
   <source media="(max-width: 1200px)" srcset="https://static.rerun.io/notebook_example/e47920b7ca7988aba305d73b2aea2da7b81c93e3/1200w.png">
 </picture>
 
-This is similar to calling `rr.connect()` or `rr.serve()` in that it configures the Rerun SDK to send data to a viewer instance.
+This is similar to calling `rr.connect_grpc()` or `rr.serve()` in that it configures the Rerun SDK to send data to a viewer instance.
 
 Note that the call to `rr.notebook_show()` drains the recording of its data. This means that any subsequent calls to `rr.notebook_show()`
 will not result in the same data being displayed, because it has already been removed from the recording.

docs/content/howto/visualization/configure-viewer-through-code.md

@@ -48,7 +48,7 @@ my_blueprint = rrb.Blueprint(
 
 ## Sending the blueprint to the Viewer
 
-To provide a blueprint, simply pass it to either `init` or `connect` using the `default_blueprint`
+To provide a blueprint, simply pass it to either `init` or `connect_grpc` using the `default_blueprint`
 parameter.
 
 Using `init` with `spawn=True`:
@@ -59,7 +59,7 @@ my_blueprint = rrb.Blueprint(...)
 rr.init("rerun_example_my_blueprint", spawn=True, default_blueprint=my_blueprint)
 ```
 
-Or if you use `connect` separate from `init`:
+Or if you use `connect_grpc` separate from `init`:
 
 ```python
 my_blueprint = rrb.Blueprint(...)
@@ -68,7 +68,7 @@ rr.init("rerun_example_my_blueprint")
 
 ...
 
-rr.connect(default_blueprint=my_blueprint)
+rr.connect_grpc(default_blueprint=my_blueprint)
 ```
 
 ## Activating the default blueprint

docs/content/reference/sdk/operating-modes.md

@@ -12,7 +12,7 @@ Before reading this document, you might want to familiarize yourself with the [R
 
 ## Operating modes
 
-The Rerun SDK provides 4 modes of operation: `spawn`, `connect`, `serve_grpc`, and `save`.
+The Rerun SDK provides 4 modes of operation: `spawn`, `connect_grpc`, `serve_grpc`, and `save`.
 
 All four of them are optional: when none of these modes are active, the client will simply buffer the logged data in memory, waiting for one of these modes to be enabled so that it can flush it.
 
@@ -30,20 +30,20 @@ Call [`rr.spawn`](https://ref.rerun.io/docs/python/stable/common/initialization_
 [`RecordingStream::spawn`](https://docs.rs/rerun/latest/rerun/struct.RecordingStream.html#method.spawn) spawns a new Rerun Viewer process using an executable available in your PATH, then streams all the data to it via gRPC. If an external Viewer was already running, `spawn` will connect to that one instead of spawning a new one.
 
 
-### `connect`
+### `connect_grpc`
 
 Connects to a remote Rerun Viewer and streams all the data via gRPC.
 
 You will need to start a stand-alone Viewer first by typing `rerun` in your terminal.
 
 #### C++
-`RecordingStream::connect`
+`RecordingStream::connect_grpc`
 
 #### Python
-[`rr.connect`](https://ref.rerun.io/docs/python/stable/common/initialization_functions/#rerun.connect)
+[`rr.connect_grpc`](https://ref.rerun.io/docs/python/stable/common/initialization_functions/#rerun.connect_grpc)
 
 #### Rust
-[`RecordingStream::connect`](https://docs.rs/rerun/latest/rerun/struct.RecordingStream.html#method.connect)
+[`RecordingStream::connect_grpc`](https://docs.rs/rerun/latest/rerun/struct.RecordingStream.html#method.connect_grpc)
 
 
 ### `serve_grpc`

examples/python/notebook/README.md

@@ -37,7 +37,7 @@ rr.notebook_show()
 This will show the contents of the current global recording stream. Note that the global stream will accumulate
 data in-memory. You can reset the stream by calling `rr.init` again to establish a new global context.
 
-As with the other stream viewing APIs (`rr.show`, `rr.connect`, `rr.spawn`), you can alternatively pass
+As with the other stream viewing APIs (`rr.show`, `rr.connect_grpc`, `rr.spawn`), you can alternatively pass
 a specific recording instance to `notebook_show`
 
 ```python

rerun_cpp/README.md

@@ -31,7 +31,7 @@ Instead of spawning a new viewer, you can also try to connect to an already open
 
 ### Buffering
 
-As long as you haven't called `rerun::RecordingStream::save`/`rerun::RecordingStream::connect`/`rerun::RecordingStream::spawn`
+As long as you haven't called `rerun::RecordingStream::save`/`rerun::RecordingStream::connect_grpc`/`rerun::RecordingStream::spawn`
 any data will be kept in memory until you call one of these.
 
 \snippet{trimleft} readme_snippets.cpp Buffering

rerun_py/rerun_bindings/rerun_bindings.pyi

@@ -817,8 +817,7 @@ def disconnect(recording: Optional[PyRecordingStream] = None) -> None:
     """
     Disconnect from remote server (if any).
 
-    Subsequent log messages will be buffered and either sent on the next call to `connect`,
-    or shown with `show`.
+    Subsequent log messages will be buffered and either sent on the next call to `connect_grpc` or `spawn`.
     """
 
 def flush(blocking: bool, recording: Optional[PyRecordingStream] = None) -> None:

rerun_py/rerun_sdk/rerun/__init__.py

@@ -272,7 +272,7 @@ def init(
         Spawn a Rerun Viewer and stream logging data to it.
         Short for calling `spawn` separately.
         If you don't call this, log events will be buffered indefinitely until
-        you call either `connect`, `show`, or `save`
+        you call either `connect_grpc`, `show`, or `save`
     default_enabled
         Should Rerun logging be on by default?
         Can be overridden with the RERUN env-var, e.g. `RERUN=on` or `RERUN=off`.

rerun_py/rerun_sdk/rerun/recording_stream.py

@@ -98,7 +98,7 @@ def new_recording(
         Spawn a Rerun Viewer and stream logging data to it.
         Short for calling `spawn` separately.
         If you don't call this, log events will be buffered indefinitely until
-        you call either `connect`, `show`, or `save`
+        you call either `connect_grpc`, `show`, or `save`
     default_enabled
         Should Rerun logging be on by default?
         Can be overridden with the RERUN env-var, e.g. `RERUN=on` or `RERUN=off`.

rerun_py/rerun_sdk/rerun/sinks.py

@@ -57,7 +57,7 @@ def connect_grpc(
 
     """
     if not is_recording_enabled(recording):
-        logging.warning("Rerun is disabled - connect() call ignored")
+        logging.warning("Rerun is disabled - connect_grpc() call ignored")
         return
 
     from rerun.recording_stream import get_application_id

rerun_py/src/python_bridge.rs

@@ -626,7 +626,7 @@ fn connect_grpc(
         .map_err(|err| PyRuntimeError::wrap(err, format!("invalid endpoint {url:?}")))?;
 
     if re_sdk::forced_sink_path().is_some() {
-        re_log::debug!("Ignored call to `connect()` since _RERUN_TEST_FORCE_SAVE is set");
+        re_log::debug!("Ignored call to `connect_grpc()` since _RERUN_TEST_FORCE_SAVE is set");
         return Ok(());
     }
 
@@ -1157,8 +1157,7 @@ fn serve_web(
 
 /// Disconnect from remote server (if any).
 ///
-/// Subsequent log messages will be buffered and either sent on the next call to `connect`,
-/// or shown with `show`.
+/// Subsequent log messages will be buffered and either sent on the next call to `connect_grpc` or `spawn`.
 #[pyfunction]
 #[pyo3(signature = (recording=None))]
 fn disconnect(py: Python<'_>, recording: Option<&PyRecordingStream>) {