Hi all,
I wanted to start a discussion about the use of Flow.Subscriber and
Flow.Publisher in JEP 321 (HTTP Client API).
It seems that users are required to implement their own publishers and
subscribers, that is, they can't take a Flow.Publisher or Flow.Subscriber
provided by another reactive st
On Thu, Dec 7, 2017 at 8:32 AM, Chris Hegarty wrote:
> David,
>
> On 07/12/17 13:14, David Lloyd wrote:
>>
>> On Thu, Dec 7, 2017 at 5:53 AM, Alan Bateman
>> wrote:
>>>
>>> This thread is getting a little off-topic but...
>>
>>
>> Getting it back on topic again:
>>
>>> Proposal for the standard m
James,
On 07/12/17 00:19, James Roper wrote:
> ...
> Your reading is correct. In my experience, it varies wildly by use case.
> In the technology I work with (Akka), we do exactly this, we have
> ByteStrings (essentially immutable byte buffer), and flow control is
> done on the number of ByteStr
David,
On 07/12/17 13:14, David Lloyd wrote:
On Thu, Dec 7, 2017 at 5:53 AM, Alan Bateman wrote:
This thread is getting a little off-topic but...
Getting it back on topic again:
Proposal for the standard module name: java.net.httpclient. Proposal for the
standard package name: java.net.ht
On Thu, Dec 7, 2017 at 5:53 AM, Alan Bateman wrote:
> This thread is getting a little off-topic but...
Getting it back on topic again:
> Proposal for the standard module name: java.net.httpclient. Proposal for the
> standard package name: java.net.http.
I think it would be better if both the m
On 07/12/2017 00:19, James Roper wrote:
:
One issue that I'm not sure about is the consequences of using direct
buffers with regards to garbage collection. If direct buffers are
never copied onto the heap, and are never reused, lets say you're just
implementing a proxy passing buffers through