Skip to content

Read-write design #54

@onkoe

Description

@onkoe

There's already an issue on metadata write support (see: #20), but I want to have an actual design for that. So, here we go!

Step 1: Memory Mapping

We'll want to avoid trying to shove 200 GiB files into memory. Let's use memmap2 to avoid doing so, and use a BufReader to get more data when we need it.

pub struct FileHash(pub [u8; 32]);

We might be able to provide the hash directly to users. It might also make sense to store the file source, if available.

Step 2: Hashing

Before doing anything to the file, we should hash the entire thing to know if the parser is "up-to-date" with its boundary knowledge. I recommend the highway crate for this task.

If we didn't do this, we could potentially write garbage into containers, ruining users' files!!!

Step 3: Reading a Full File

For binary data inside blocks/atoms/boxes/whatever, we shouldn't try to load any of that -- only store its bounding box. For example:

pub struct BoundingBox {
    start: u64,
	end: u64,
}

Everything else that can be parsed into actual structures should be. Each provider format should be entirely supported -- there should be unsupported/forgotten blocks.

Step 4: Writing

I want a way to automatically write files with the same logic that reads them. So...

TODO

Metadata

Metadata

Assignees

Labels

api/ergonomicsThis task changes the crate's ergonomics and usability

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions