You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, an RRD stream (which might be coming from a file (or 10) or a socket or whatever else) is allowed to contain any number and any type (i.e. data vs. blueprint) of recordings within it.
This means that everything that handles RRD streams has to be able to deal with the multi-recordings case.
This adds a lot of complexity everywhere (hashmaps, errors, etc), all the way to the end-users.
We should have a dedicated Rerun Archive format for these places where it is indeed a useful construct, and constrain RRD streams to a single recordings, always.
Most APIs would work at the RRD level, and therefore become simple both to use and implement, and users could easily get recordings in and out of rerun archives using dedicated APIs and/or CLI tools.
The text was updated successfully, but these errors were encountered:
Today, an RRD stream (which might be coming from a file (or 10) or a socket or whatever else) is allowed to contain any number and any type (i.e. data vs. blueprint) of recordings within it.
This means that everything that handles RRD streams has to be able to deal with the multi-recordings case.
This adds a lot of complexity everywhere (hashmaps, errors, etc), all the way to the end-users.
We should have a dedicated Rerun Archive format for these places where it is indeed a useful construct, and constrain RRD streams to a single recordings, always.
Most APIs would work at the RRD level, and therefore become simple both to use and implement, and users could easily get recordings in and out of rerun archives using dedicated APIs and/or CLI tools.
The text was updated successfully, but these errors were encountered: