Struct tvix_castore::proto::GRPCBlobServiceWrapper

pub struct GRPCBlobServiceWrapper<T> {
    blob_service: T,
}

Fields

blob_service: T

Implementations

impl<T> GRPCBlobServiceWrapper<T>

pub fn new(blob_service: T) -> Self

Trait Implementations

impl<T> BlobService for GRPCBlobServiceWrapper<T>

where T: Deref<Target = dyn BlobService> + Send + Sync + 'static,

type ReadStream = Pin<Box<dyn Stream<Item = Result<BlobChunk, Status>> + Send>>

Server streaming response type for the Read method.

fn stat<'life0, 'async_trait>( &'life0 self, request: Request<StatBlobRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<StatBlobResponse>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Stat can be used to check for the existence of a blob, as well as gathering more data about it, like more granular chunking information or baos. Server implementations are not required to provide more granular chunking information, especially if the digest specified in StatBlobRequest is already a chunk of a blob.

fn read<'life0, 'async_trait>( &'life0 self, request: Request<ReadBlobRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<Self::ReadStream>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Read allows reading (all) data of a blob/chunk by the BLAKE3 digest of its contents. If the backend communicated more granular chunks in the Stat request, this can also be used to read chunks. This request returns a stream of BlobChunk, which is just a container for a stream of bytes. The server may decide on whatever chunking it may seem fit as a size for the individual BlobChunk sent in the response stream, this is mostly to keep individual messages at a manageable size.

fn put<'life0, 'async_trait>( &'life0 self, request: Request<Streaming<BlobChunk>>, ) -> Pin<Box<dyn Future<Output = Result<Response<PutBlobResponse>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Put uploads a Blob, by reading a stream of bytes.