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
