Skip to main content

DataLoader

rerun

Trait DataLoader 

Source 
pub trait DataLoader: Send + Sync {
    // Required methods
    fn name(&self) -> String;
    fn import_from_path(
        &self,
        settings: &ImporterSettings,
        path: PathBuf,
        tx: Sender<ImportedData>,
    ) -> Result<(), ImporterError>;
    fn import_from_file_contents(
        &self,
        settings: &ImporterSettings,
        filepath: PathBuf,
        contents: Cow<'_, [u8]>,
        tx: Sender<ImportedData>,
    ) -> Result<(), ImporterError>;
}
Expand description

An Importer imports data from a file path and/or a file’s contents.

Files can be imported 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 importing methods support importing 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 importing 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 Importers by default:

§Registering custom importers

Checkout our guide.

§Execution

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

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

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

On native, Importers are executed in parallel.

Required Methods§

Source

fn name(&self) -> String

Name of the Importer.

Should be globally unique.

Source

fn import_from_path( &self, settings: &ImporterSettings, path: PathBuf, tx: Sender<ImportedData>, ) -> Result<(), ImporterError>

Imports 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 importing 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 import_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 an Importer has no interest in the given file, it should fail as soon as possible with a ImporterError::Incompatible error.

Source

fn import_from_file_contents( &self, settings: &ImporterSettings, filepath: PathBuf, contents: Cow<'_, [u8]>, tx: Sender<ImportedData>, ) -> Result<(), ImporterError>

Imports 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 importing 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 import_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 an Importer has no interest in the given file, it should fail as soon as possible with a ImporterError::Incompatible error.

Implementors§