By NIO2, I meant the following style of flow-control (back-pressure), in
pseudo code:
channel.notifywhenreadable(callback) // edge trigger ideally
channel.notifywhenwritable(callback)
int channel.availablebytes();
int channel.read(int, buf);// always from callback
int channel.write(buf);
Actually, thinking about this again. There is an obviously better way of
notifying request completion, by just de-coupling the send and the receive
explicitly, while still keeping a way to do both together.
1. 2. and 3. below would be replaced with the following:
(HttpRequest)
void send() -> blo
Here is what I propose on some of the issues you raised yesterday:
1. make it clear that HttpRequest.send() blocks until entire request is sent
and the response headers received.
2. Add a new method to HttpRequest
/**
* Notifies when this request has been completely sent. If the
re
Wenbo,
On WebSockets, that API work is being handled separately to this work
and will be put out for review very soon.
- Michael
On 31/07/15 19:37, Wenbo Zhu wrote:
On Fri, Jul 31, 2015 at 11:32 AM, Simone Bordet
mailto:simone.bor...@gmail.com>> wrote:
Hi,
On Fri, Jul 31, 2015 a
Hi,
On Fri, Jul 31, 2015 at 8:37 PM, Wenbo Zhu wrote:
>> > Or we follow the NIO2 model (readiness),
>>
>> Please no ! :)
>
> Ignoring the epoll part, is the issue in the API styles or the actual model?
https://webtide.com/on-jdk-7-asynchronous-io/
and
http://www.slideshare.net/SimoneBordet/ser
On Fri, Jul 31, 2015 at 11:32 AM, Simone Bordet
wrote:
> Hi,
>
> On Fri, Jul 31, 2015 at 7:54 PM, Wenbo Zhu wrote:
> > Thanks for the update.
> >
> > ===
> >
> > Is WebSocket out of the scope now?
> >
> > == async streams
> >
> > I.e. how bodies are to be read/written asynchronously, with flow-c
Hi,
On Fri, Jul 31, 2015 at 7:54 PM, Wenbo Zhu wrote:
> Thanks for the update.
>
> ===
>
> Is WebSocket out of the scope now?
>
> == async streams
>
> I.e. how bodies are to be read/written asynchronously, with flow-control
> (aka back pressures).
>
> There are many different styles or abstractio
Hi,
On Fri, Jul 31, 2015 at 6:33 PM, Michael McMahon
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 an
On 31/07/15 16:06, Simone Bordet wrote:
Hi,
On Fri, Jul 31, 2015 at 3:56 PM, Michael McMahon
wrote:
Ok. Now, on the whole flow-control issue, here is my thinking.
First that isFast() method is a relic from a previous version and should not
have been there.
My thinking is that the body process
Hi,
On Fri, Jul 31, 2015 at 4:19 PM, Michael McMahon
wrote:
> Sorry, just on that point again. It was never intended to support
> anything other than URIs here, whether as a String or URI object.
> We don't want to allow CONNECTs directly and since it is possible
> to create a request without a U
Hi,
On Fri, Jul 31, 2015 at 3:56 PM, Michael McMahon
wrote:
> Ok. Now, on the whole flow-control issue, here is my thinking.
> First that isFast() method is a relic from a previous version and should not
> have been there.
>
> My thinking is that the body processing methods of the response
> body
On 31/07/15 14:56, Michael McMahon wrote:
T
== HttpRequest.create(URI) and related.
Using a URI is not correct since requests may be made for targets that
are not URIs, see https://tools.ietf.org/html/rfc7230#section-5.3.
Examples: OPTIONS * HTTP/1.1, CONNECT foo:9090 HTTP/1.1 where "*" and
"fo
Thanks for the quick review, Simone.
Some answers below.
Michael
On 31/07/15 14:10, Simone Bordet wrote:
Hi,
On Fri, Jul 31, 2015 at 9:00 AM, Michael McMahon
wrote:
Hi Wenbo,
The latest version of the docs is available at:
http://cr.openjdk.java.net/~michaelm/8087112/2/
I am hoping to final
Hi,
On Fri, Jul 31, 2015 at 9:00 AM, Michael McMahon
wrote:
> Hi Wenbo,
>
> The latest version of the docs is available at:
> http://cr.openjdk.java.net/~michaelm/8087112/2/
> I am hoping to finalize this very soon.
Comments below.
== HttpRequest.create(URI) and related.
Using a URI is not corr
Hi Wenbo,
The latest version of the docs is available at:
http://cr.openjdk.java.net/~michaelm/8087112/2/
I am hoping to finalize this very soon.
Thanks,
Michael.
On 31/07/15 00:26, Wenbo Zhu wrote:
Has the API docs been moved? Is there an updated version of it?
Thanks,
Wenbo
On Mon, Mar 9,
Hi Michael
Further feedback is in-line (please note that, to improve readability, I
took the liberty to discard points without further feedback).
On 25/03/2015 18:33, Michael McMahon wrote:
* how is compression (the
Accept-Encoding/Content-Encoding/Transfer-Encoding headers) handled?
Is this
Hi Anthony,
Comments/answers below
On 21/03/15 10:44, Anthony Vanelverdinghe wrote:
Hi Michael
Please find my feedback on the current API docs below. It's divided in
3 parts: API (mostly questions), documentation (mostly suggestions for
clarifications) and spelling.
Thanks in advance for y
Hi Michael
Please find my feedback on the current API docs below. It's divided in 3
parts: API (mostly questions), documentation (mostly suggestions for
clarifications) and spelling.
Thanks in advance for your consideration.
Kind regards, Anthony
=== API ===
* will there be support for HTTP
18 matches
Mail list logo
