pub enum UploadSessionTransport {
ServiceProxied {},
DirectPut {
promised_content: ContentRef,
},
DirectMultipart {
provider_upload_id: String,
part_size_bytes: NonZeroU64,
},
}Expand description
How one upload session moves its bytes into object storage, and everything that choice settles before any byte moves.
A session’s transport is fixed when it opens and never changes. Each variant carries exactly what its own path needs, so a session cannot hold a provider upload it will never use, or a promise it was never given.
Variants§
ServiceProxied
The service receives the bytes and writes the content object itself, so it learns size and digest from the bytes as they pass and has nothing to record here.
The empty braces are load-bearing: serde lets a unit variant of a
tagged enum swallow whatever else the object carried, so spelling
this as ServiceProxied would read a record holding a provider
upload as a proxied session and drop the handle that cleans it up.
A variant with no fields refuses it as the corruption it is.
DirectPut
The client writes the whole object through one presigned request.
Fields
promised_content: ContentRefThe reference that signed write is minted for.
A direct-put client declares its byte length and SHA-256 before the write is authorized, because both are signed into the request and the provider refuses any body that does not match. Completion reads the stored object back against this same reference rather than believing it.
DirectMultipart
The client writes the object in parts through presigned part uploads, and the provider assembles it.
There is deliberately no content promise here. A session that had to declare its length and digest up front would make a one-pass uploader read its payload twice, and a client reading from a pipe could not start at all — so a multipart upload claims what it wrote at completion, which is where it was always verified rather than believed. This variant carrying no reference is what makes an up-front multipart claim unrepresentable.
Fields
provider_upload_id: StringThe provider-side upload the parts assemble through, and the only provider handle LoonFS keeps: parts are the client’s bookkeeping, exactly as they are in the provider’s own API, so there is no durable record per part.
part_size_bytes: NonZeroU64Byte length of every part except the last, settled at begin.
A session resumed after a lost begin response reads its geometry from here rather than being told a second, possibly different, one. Zero is not a geometry, so it is not representable.
Trait Implementations§
Source§impl Clone for UploadSessionTransport
impl Clone for UploadSessionTransport
Source§fn clone(&self) -> UploadSessionTransport
fn clone(&self) -> UploadSessionTransport
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more