Trait rerun::DataLoader

source · 
pub trait DataLoader: Send + Sync {
    // Required methods
    fn name(&self) -> String;
    fn load_from_path(
        &self,
        settings: &DataLoaderSettings,
        path: PathBuf,
        tx: Sender<LoadedData>
    ) -> Result<(), DataLoaderError>;
    fn load_from_file_contents(
        &self,
        settings: &DataLoaderSettings,
        filepath: PathBuf,
        contents: Cow<'_, [u8]>,
        tx: Sender<LoadedData>
    ) -> Result<(), DataLoaderError>;
}
Expand description

A DataLoader loads data from a file path and/or a file’s contents.

Files can be loaded in 3 different ways:

  • via the Rerun CLI (rerun myfile.jpeg),
  • using drag-and-drop,
  • using the open dialog in the Rerun Viewer.

All these file loading methods support loading a single file, many files at once, or even folders. ⚠ Drag-and-drop of folders does not yet work on the web version of Rerun Viewer ⚠

We only support loading files from the local filesystem at the moment, and consequently only accept filepaths as input. There are plans to make this generic over any URI.

Rerun comes with a few DataLoaders by default:

§Registering custom loaders

Checkout our guide.

§Execution

All known DataLoaders get called when a user tries to open a file, unconditionally. This gives DataLoaders maximum flexibility to decide what files they are interested in, as opposed to e.g. only being able to look at files’ extensions.

If a DataLoader has no interest in the given file, it should fail as soon as possible with a DataLoaderError::Incompatible error.

Iff all DataLoaders (including custom and external ones) return with a DataLoaderError::Incompatible error, the Viewer will show an error message to the user indicating that the file type is not supported.

On native, DataLoaders are executed in parallel.

Required Methods§

source

fn name(&self) -> String

Name of the DataLoader.

Should be globally unique.

source

fn load_from_path( &self, settings: &DataLoaderSettings, path: PathBuf, tx: Sender<LoadedData> ) -> Result<(), DataLoaderError>

Loads data from a file on the local filesystem and sends it to tx.

This is generally called when opening files with the Rerun CLI or via the open menu in the Rerun Viewer on native platforms.

The passed-in store_id is a shared recording created by the file loading machinery: implementers can decide to use it or not (e.g. it might make sense to log all images with a similar name in a shared recording, while an rrd file is already its own recording).

path isn’t necessarily a file path, but can be a directory as well: implementers are free to handle that however they decide.

§Error handling

Most implementers of load_from_path are expected to be asynchronous in nature.

Asynchronous implementers should make sure to fail early (and thus synchronously) when possible (e.g. didn’t even manage to open the file). Otherwise, they should log errors that happen in an asynchronous context.

If a DataLoader has no interest in the given file, it should fail as soon as possible with a DataLoaderError::Incompatible error.

source

fn load_from_file_contents( &self, settings: &DataLoaderSettings, filepath: PathBuf, contents: Cow<'_, [u8]>, tx: Sender<LoadedData> ) -> Result<(), DataLoaderError>

Loads data from in-memory file contents and sends it to tx.

This is generally called when opening files via drag-and-drop or when using the web viewer.

The passed-in store_id is a shared recording created by the file loading machinery: implementers can decide to use it or not (e.g. it might make sense to log all images with a similar name in a shared recording, while an rrd file is already its own recording).

The path of the file is given for informational purposes (e.g. to extract the file’s extension): implementers should not try to read from disk as there is likely isn’t a filesystem available to begin with. path is guaranteed to be a file path.

When running on the web (wasm), filepath only contains the file name.

§Error handling

Most implementers of load_from_file_contents are expected to be asynchronous in nature.

Asynchronous implementers should make sure to fail early (and thus synchronously) when possible (e.g. didn’t even manage to open the file). Otherwise, they should log errors that happen in an asynchronous context.

If a DataLoader has no interest in the given file, it should fail as soon as possible with a DataLoaderError::Incompatible error.

Implementors§