You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by Ignasi Barrera <no...@github.com> on 2019/01/18 16:03:02 UTC

Re: [jclouds/jclouds] JCLOUDS-769: streaming putBlob (#1129)

Hmmmmm, I see where you're going.

The main issue I see with this approach is that a client won't know actually when a streaming request has finished, and won't have access to the response code, which might be important...
How are we handling streaming requests to endpoints return a redirect (3xx) we should follow before posting the content?

Access to the response status is important, and that was one of my reasons to suggest the specialized payload approach. My thinking was something like having a specialised binding for, say, `Writer` parameters in API methods, and handle that at the writer level by blocking until the writer is done, then completing the method call and returning following the existing flows and response and error handling mechanisms.

Something like:

```java
@Named("PutObject")
@PUT
@Path("/{key}")
@Headers(keys = EXPECT, values = "100-continue")
@ResponseParser(ReturnOutputStream.class)
ETagOutputStream putObjectStreaming(
      @Bucket @EndpointParam(parser = AssignCorrectHostnameForBucket.class) @BinderParam(BindAsHostPrefixIfConfigured.class) @ParamValidators(BucketNameValidator.class) String bucketName,
      @PathParam("key") @ParamParser(ObjectKey.class) @BinderParam(BindS3ObjectMetadataToRequest.class) S3Object object,
      Writer streamingContent,   // This is an object the client controlls that should be piped to the request outputstream
      PutObjectOptions... options);
```

Does this make sense?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1129#issuecomment-455596882