Hi,
On Fri, Jul 31, 2015 at 6:33 PM, Michael McMahon
<michael.x.mcma...@oracle.com> wrote:
> Well, it needs co-operation between the producer and the consumer
> obviously. But, the onResponseBodyChunk() method could write to a queue
> and block if it reaches a certain size. The onRequestBodyChunk() would
> read off the data and send it on. When the queue reaches a lower limit it
> notifies the producer to continue. It's not asynchronous, but is possible
> and I'm not sure we're aiming at this type of application.
Sure, it's possible to implement it in a blocking way with the current APIs.
But the whole world is moving to asynchronous APIs, so... :)
> Having said that, this is an area we planned to look at again, after the
> initial putback.
Great! Please notify this list when you have a further revision to review.
> Strangely, Future.cancel() doesn't specify any such restriction, but
> CompletableFuture.cancel() does. In theory, one could sub-class
> CompletableFuture and implement cancellation behavior that way,
> but the intent does seem to be that cancellation should come from outside
> and just be reported through this class. And considering the point above
> about stopping runaway request sends then maybe an explicit
> cancellation API would be useful.
Right. Just remember that in my experience, supporting abort() would
complicate the implementation a lot, but I guess it's just an
implementation detail.
>> IMHO the API is confusing, I prefer just doing builder.header("Foo",
>> "foovalue").header("Bar", "barvalue").
>
>
> the parameters have to be specified in pairs
> with (header name first, then value) * n
Right, but you cannot enforce that, so the API is brittle, hence my dislike :)
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
