package rerun.log_msg.v1alpha1

Mouse Melon logoGet desktop application:
View/edit binary Protocol Buffers messages

message ArrowMsg

log_msg.proto:54

Corresponds to `LogMsg::ArrowMsg`. Used to transmit actual data.

Used in: cloud.v1alpha1.FetchChunksResponse, LogMsg

message BlueprintActivationCommand

log_msg.proto:81

Corresponds to `LogMsg::BlueprintActivationCommand`. Used for activating a blueprint once it has been fully transmitted, because showing a blueprint before it is fully transmitted can lead to a confusing user experience, or inconsistent results due to heuristics.

Used in: LogMsg

message CrateInfo

log_msg.proto:179

Information about the Rust SDK that created the recording.

enum Encoding

log_msg.proto:45

The encoding of the message payload.

Used in: ArrowMsg

message FileSource

log_msg.proto:188

A recording which came from a file.

enum FileSourceKind

log_msg.proto:193

Determines where the file came from.

Used in: FileSource

message LogMsg

log_msg.proto:22

There are 3 different `LogMsg`-related types that you will very often encounter: `re_log_types::LogMsg`, `re_protos::log_msg::v1alpha1::LogMsg` and `re_protos::log_msg::v1alpha1::log_msg::Msg`. Mixing them up is a common source of pain and confusion, so let's go over what each does: * `re_log_types::LogMsg` is the application-level type that we use all across the viewer codebase. It can be obtained by calling `to_application()` on one of the transport-level `LogMsg` types which, among many other things, will perform Chunk/Sorbet-level migrations. `re_log_types::LogMsg` isn't used in Redap, where everything is done at the transport-level, always. * `re_protos::log_msg::v1alpha1::LogMsg` is the transport-level definition of `LogMsg`. It is an artifact of how `oneof` works in Protobuf: all it does is carry a `re_protos::log_msg::v1alpha1::log_msg::Msg`. For that reason, it is never directly used, except by the legacy SDK comms protocol. * Finally, `re_protos::log_msg::v1alpha1::log_msg::Msg` is the real transport-level type that we care about. It is used all over the place when encoding and decoding RRD streams. TODO(#8631): Remove `LogMsg`

Used in: sdk_comms.v1alpha1.ReadMessagesResponse, sdk_comms.v1alpha1.WriteMessagesRequest

message PythonVersion

log_msg.proto:171

Version of the Python SDK that created the recording.

message RrdFooter

log_msg.proto:234

This is the payload that is carried in messages of type `::End` in RRD streams. It keeps track of various useful information about the associated recording. During normal operations, there can only be a single `::End` message in an RRD stream, and therefore a single `RrdFooter`. It is possible to break that invariant by concatenating streams using external tools, e.g. by doing something like `cat *.rrd > all_my_recordings.rrd`. Passing that stream back through Rerun tools, e.g. `cat *.rrd | rerun rrd merge > all_my_recordings.rrd`, would once again guarantee that only one `::End` message is present though. I.e. that invariant holds as long as one stays within our ecosystem of tools. This is a transport-level type, the associated application-level type can be found in `re_log_encoding::RrdFooter`.

message RrdManifest

log_msg.proto:254

This is the payload found in `RrdFooter`s. Each `RrdManifest` corresponds to one, and exactly one, RRD stream (i.e. recording). This restriction exists to make working with multiple RRD streams much simpler: due to the way the Rerun data model works, filtering rows of data from a manifest can have hard-to-predict second order effects on the schema of the stream as a whole. By keeping manifests for different recordings separate, we remove the need to filter per recording ID, greatly simplifying the process. This is a transport-level type, the associated application-level type can be found in `re_log_encoding::RrdManifest`.

Used in: cloud.v1alpha1.GetRrdManifestResponse, RrdFooter

message SetStoreInfo

log_msg.proto:36

Corresponds to `LogMsg::SetStoreInfo`. Used to identify a recording.

Used in: LogMsg

message StoreInfo

log_msg.proto:93

Information about a recording or blueprint.

Used in: SetStoreInfo

message StoreSource

log_msg.proto:117

The source of a recording or blueprint.

Used in: StoreInfo

message StoreSourceExtra

log_msg.proto:128

A newtype for `StoreSource` payload. This exists to that we can implement conversions on the newtype for convenience.

Used in: StoreSource

enum StoreSourceKind

log_msg.proto:133

What kind of source a recording comes from.

Used in: StoreSource

message StoreVersion

log_msg.proto:213

Used in: StoreInfo