I've finally had some time to look at this. Thanks for starting this proposal!
I like the idea of having the API methods return a stream clients can write to, but I'm not sure about several things that are needed to have that. It's weird for me to have an OutputStream in the HttpResponse. If I get it right it's there just to be accessible from the response transformers, a convenient way to propagate it to the API return value. But it looks weird; I understood it better if it was in the request. We should also take into account that, although not so widely used, there is a generic Http utils class that allows using the HttpRequest and HttpResponse directly, and there are also binders and transformers for those objects. If we modify the request/response objects we need to make sure the features we already leverage that use them directly can still be used with the new additions. This said, could an alternate approach be payload-based? I mean, instead of changing the return type of a method, could we play with specialized Payloads instead? For example, with the [OkHttp driver we're already streaming data](https://github.com/jclouds/jclouds/blob/master/drivers/okhttp/src/main/java/org/jclouds/http/okhttp/OkHttpCommandExecutorService.java#L120-L146). Could we modify that to let clients provide a specialized payload that leveraged the streaming PUT? I think a PoC with this driver and specific payloads would also be great. -- 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-330141894
