about summary refs log tree commit diff
path: root/tvix/store/protos
diff options
context:
space:
mode:
authorFlorian Klink <flokli@flokli.de>2023-05-11T12·49+0300
committerflokli <flokli@flokli.de>2023-05-11T14·27+0000
commit616fa4476f93e1782e68dc713e9e8cb77a426c7d (patch)
treef76a43e95c75d848d079706fbccfd442210ebebc /tvix/store/protos
parentb22b685f0b2524c088deacbf4e80e7b7c73b5afc (diff)
refactor(tvix/store): remove ChunkService r/6133
Whether chunking is involved or not, is an implementation detail of each
Blobstore. Consumers of a whole blob shouldn't need to worry about that.
It currently is not visible in the gRPC interface either. It
shouldn't bleed into everything.

Let the BlobService trait provide `open_read` and `open_write` methods,
which return handles providing io::Read or io::Write, and leave the
details up to the implementation.

This means, our custom BlobReader module can go away, and all the
chunking bits in there, too.

In the future, we might still want to add more chunking-aware syncing,
but as a syncing strategy some stores can expose, not as a fundamental
protocol component.

This currently needs "SyncReadIntoAsyncRead", taken and vendored in from
https://github.com/tokio-rs/tokio/pull/5669.
It provides a AsyncRead for a sync Read, which is necessary to connect
our (sync) BlobReader interface to a GRPC server implementation.

As an alternative, we could also make the BlobReader itself async, and
let consumers of the trait (EvalIO) deal with the async-ness, but this
is less of a change for now.

In terms of vendoring, I initially tried to move our tokio crate to
these commits, but ended up in version incompatibilities, so let's
vendor it in for now.

Change-Id: I5969ebbc4c0e1ceece47981be3b9e7cfb3f59ad0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8551
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
Diffstat (limited to 'tvix/store/protos')
-rw-r--r--tvix/store/protos/rpc_blobstore.proto9
-rw-r--r--tvix/store/protos/rpc_blobstore_grpc.pb.go20
2 files changed, 0 insertions, 29 deletions
diff --git a/tvix/store/protos/rpc_blobstore.proto b/tvix/store/protos/rpc_blobstore.proto
index c0665e821a..a7d48cf770 100644
--- a/tvix/store/protos/rpc_blobstore.proto
+++ b/tvix/store/protos/rpc_blobstore.proto
@@ -21,15 +21,6 @@ service BlobService {
     // The server may decide on whatever chunking it may seem fit as a size for
     // the individual BlobChunk sent in the response stream.
     //
-    // It specifically is NOT necessarily using chunk sizes communicated in a
-    // previous Stat request.
-    //
-    // It's up to the specific store to decide on whether it allows Read on a
-    // Blob at all, or only on smaller chunks communicated in a Stat() call
-    // first.
-    //
-    // Clients are enouraged to Stat() first, and then only read the individual
-    // chunks they don't have yet.
     rpc Read(ReadBlobRequest) returns (stream BlobChunk);
 
     // Put uploads a Blob, by reading a stream of bytes.
diff --git a/tvix/store/protos/rpc_blobstore_grpc.pb.go b/tvix/store/protos/rpc_blobstore_grpc.pb.go
index 5199fe1511..3842ea2885 100644
--- a/tvix/store/protos/rpc_blobstore_grpc.pb.go
+++ b/tvix/store/protos/rpc_blobstore_grpc.pb.go
@@ -43,16 +43,6 @@ type BlobServiceClient interface {
 	//
 	// The server may decide on whatever chunking it may seem fit as a size for
 	// the individual BlobChunk sent in the response stream.
-	//
-	// It specifically is NOT necessarily using chunk sizes communicated in a
-	// previous Stat request.
-	//
-	// It's up to the specific store to decide on whether it allows Read on a
-	// Blob at all, or only on smaller chunks communicated in a Stat() call
-	// first.
-	//
-	// Clients are enouraged to Stat() first, and then only read the individual
-	// chunks they don't have yet.
 	Read(ctx context.Context, in *ReadBlobRequest, opts ...grpc.CallOption) (BlobService_ReadClient, error)
 	// Put uploads a Blob, by reading a stream of bytes.
 	//
@@ -160,16 +150,6 @@ type BlobServiceServer interface {
 	//
 	// The server may decide on whatever chunking it may seem fit as a size for
 	// the individual BlobChunk sent in the response stream.
-	//
-	// It specifically is NOT necessarily using chunk sizes communicated in a
-	// previous Stat request.
-	//
-	// It's up to the specific store to decide on whether it allows Read on a
-	// Blob at all, or only on smaller chunks communicated in a Stat() call
-	// first.
-	//
-	// Clients are enouraged to Stat() first, and then only read the individual
-	// chunks they don't have yet.
 	Read(*ReadBlobRequest, BlobService_ReadServer) error
 	// Put uploads a Blob, by reading a stream of bytes.
 	//