Re: WebSocket client API

On 10/20/2015 12:49 PM, Simone Bordet wrote: >CharBuffer message = ... get buffer from pool or create new one ... > >... fill message with data ... > >CompletionStage cs = listener.onText(..., message, ...); > >if (cs != null) { > cs.thenAccept(cb -> { > if (cb != null) { >

Re: WebSocket client API

Hi, I think this is a reasonable observation. We actually changed ProxySelector itself to provide (one) simple factory method for a fixed Proxy using an InetSocketAddress for all requests and that makes setting a simple proxy very easy. But, I agree it probably makes more sense for the default

Re: WebSocket client API

On 10/20/2015 12:49 PM, Simone Bordet wrote: if (cs != null) { cs.thenAccept(cb -> { if (cb != null) { return*message* to buffer pool ... } }); } At that point, the return value of onText() could well be a CF like it already is, no ? The

Re: WebSocket client API

> On 19 Oct 2015, at 22:37, Simone Bordet wrote: > > Now I am confused :) > > Are you saying that if you do: > > builder.headers("foo", "bar", "baz").headers("one", "two", "three") > > then "foo", "bar" and "baz" are removed ? In the current version it is exactly

Re: WebSocket client API

> On 20 Oct 2015, at 14:32, Simone Bordet wrote: > > So why choosing CharBuffer ? Because in general when an API provides a callback method `c` c( x) an application has to implement, it should better be the case that the is the most specific type possible (with

Re: WebSocket client API

Hi, On Wed, Oct 21, 2015 at 1:29 PM, Pavel Rappo wrote: > Well, maybe, I don't know. But implementing interfaces A and B with the same > class C doesn't magically bring B's methods into A, does it? It does if they were not magically split without reason. My point is

Re: WebSocket client API

Hi, On Wed, Oct 21, 2015 at 12:52 PM, Pavel Rappo wrote: >>> But I'm against of merging flowController with WebSocket. >> >> Yet, you did not bring any technical reasons for the split, and >> "separation of concerns" is just not enough because it can mean >> anything (and

Re: WebSocket client API

> On 21 Oct 2015, at 12:18, Simone Bordet wrote: > > I really hope you meant that Listener is like Flow.Subscriber. It's obviously a typo. Thanks! Listener ~ Subscriber WebSocket ~ Publisher FlowController ~ Subscription

Re: WebSocket client API

> On 21 Oct 2015, at 12:18, Simone Bordet wrote: > > Speaking of analogies, it's pretty common to implement Publisher *and* > Subscription in the same class when you can only have one listener, > which is exactly the WebSocket case. Well, maybe, I don't know. But

Re: WebSocket client API

On 10/18/2015 12:08 AM, Pavel Rappo wrote: Hi Joakim, On 17 Oct 2015, at 22:42, Joakim Erdfelt wrote: You are required, per the RFC6455 spec, to validate incoming and outgoing TEXT messages are valid UTF8. (also Handshake and Close Reason Messages)

Re: WebSocket client API

Hi, Another thought about [Char|Byte]Buffer recycling. If the onXXX call-backs returned a CF so that they could asynchronously signal when they are done with consumption, the signature of the method could be: CompletionStage onText(..., CharBuffer cb, ...) Implementor of the method (the

Re: WebSocket client API

Hi, On Tue, Oct 20, 2015 at 11:07 AM, Peter Levart wrote: > Hi, > > Another thought about [Char|Byte]Buffer recycling. If the onXXX call-backs > returned a CF so that they could asynchronously signal when they are done > with consumption, the signature of the method could

Re: WebSocket client API

You know that CharBuffer doesn't actually do UTF8, right? It's just a ByteBuffer split into equal 2 byte segments. CharBuffer is a way to obtain char (the 2 byte number, not the character) from the ByteBuffer or String you created it from. CharBuffer is functionally no different than ShortBuffer.

Re: WebSocket client API

Hi Joakim, > On 20 Oct 2015, at 13:50, Joakim Erdfelt wrote: > > You know that CharBuffer doesn't actually do UTF8, right? > It's just a ByteBuffer split into equal 2 byte segments. > CharBuffer is a way to obtain char (the 2 byte number, not the character) > from the

Re: WebSocket client API

I'm done with the UTF8 topic, you seem to have it in hand. If you feel the existing facilities can handle it, go for it. Just don't forget to test your impl on Autobahn Testsuite. On Tue, Oct 20, 2015 at 3:06 PM, Pavel Rappo wrote: > Hi Joakim, > > > On 20 Oct 2015, at

Re: WebSocket client API

Hi Joakim, > On 20 Oct 2015, at 14:37, Joakim Erdfelt wrote: > > But we *think* we understand what you are trying to do. > > Here's a split UTF8 scenario (just whipped up) > https://gist.github.com/joakime/e34b727a6989ca7cef94 > > So the JVM implementation side will

Re: WebSocket client API

The CharBuffer requirement *was* baffling. But we *think* we understand what you are trying to do. Here's a split UTF8 scenario (just whipped up) https://gist.github.com/joakime/e34b727a6989ca7cef94 So the JVM implementation side will take the raw bytes (presumably as a ByteBuffer), and when the

Re: WebSocket client API

Hi, On Tue, Oct 20, 2015 at 2:57 PM, Pavel Rappo wrote: > Hi Joakim, > >> On 20 Oct 2015, at 13:50, Joakim Erdfelt wrote: >> >> You know that CharBuffer doesn't actually do UTF8, right? >> It's just a ByteBuffer split into equal 2 byte segments.

Re: WebSocket client API

Hi Pavel, the JavaDocs for the method HttpClient.Builder#proxy(java.net.ProxySelector selector) say: Sets a ProxySelector for this client. If no selector is set, then no proxies are used. If a null parameter is supplied then the system wide default proxy selector is used. Really? For me it

Re: WebSocket client API

> On 16 Oct 2015, at 22:11, Simone Bordet wrote: > > Hi, > > On Fri, Oct 16, 2015 at 12:35 PM, Pavel Rappo wrote: >> Hi, >> >> Here's a second update on the WebSocket API: >> >> webrev: http://cr.openjdk.java.net/~prappo/8087113/webrev.02/

Re: WebSocket client API

On Sat, Oct 17, 2015 at 11:56 AM, Pavel Rappo wrote: > > >> * WebSocket.Builder no longer accepts HttpRequest.Builder; only > HttpClient > >> * One Listener instead of many onXXX handlers > > > > I tried to write a few examples with this API, and it's a bit cumbersome >

Re: WebSocket client API

Hi Joakim, > On 17 Oct 2015, at 22:42, Joakim Erdfelt wrote: > > You are required, per the RFC6455 spec, to validate incoming and outgoing > TEXT messages are valid UTF8. > (also Handshake and Close Reason Messages) > > http://tools.ietf.org/html/rfc6455#section-8.1

Re: WebSocket client API

Resending with the right subject... not sure what Gmail was thinking. Sorry for the double send. Hi, On Fri, Oct 16, 2015 at 12:35 PM, Pavel Rappo wrote: > Hi, > > Here's a second update on the WebSocket API: > > webrev:

Re: WebSocket client API

as a means of asynchronous completion signalling * StatusCode is now ClosureCode -Pavel > On 31 Aug 2015, at 15:30, Pavel Rappo <pavel.ra...@oracle.com> wrote: > > Hi, > > I would appreciate if you help to review a WebSocket client API proposed for > JDK 9. This w

Re: WebSocket client API

Hi Pavel, There's a RFR being discussed on core-libs-dev: "8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization". Although it does not currently support it, I have been doing experiments with FinalReference(s) (a package-private subtype of Reference that is used

Re: WebSocket client API

Hi, On Tue, Oct 13, 2015 at 10:02 PM, Chris Hegarty wrote: >> Here is a proposed mechanism for managing buffers used by Listener. > > I think that this is quite good. There is clearly a need for the receiving > callbacks, onXXX methods, to allocate ( since they pass the

Re: WebSocket client API

Hi Simone, > On 8 Oct 2015, at 20:51, Simone Bordet wrote: > > The *API* should provide a callback to notify when the ByteBuffer has > been consumed. Here is a proposed mechanism for managing buffers used by Listener. 1. WebSocket.Builder gets 2 new methods (may not

Re: WebSocket client API

Pavel, > On 13 Oct 2015, at 10:40, Pavel Rappo wrote: > > Hi Simone, > >> On 8 Oct 2015, at 20:51, Simone Bordet wrote: >> >> The *API* should provide a callback to notify when the ByteBuffer has >> been consumed. > > Here is a proposed

Re: WebSocket client API

Hi, On Fri, Oct 9, 2015 at 3:18 PM, Pavel Rappo wrote: >> On 8 Oct 2015, at 20:51, Simone Bordet wrote: >> For example, this is going to surprise users (simple echo): >> >> onBinary((ws, bytes, last) -> { >>ws.sendBinary(bytes, last, null,

Re: WebSocket client API

Hi, On Fri, Oct 9, 2015 at 5:07 PM, Paul Sandoz wrote: > Regarding resource management. This one is tricky. For HTTP Michael had a > clever trick of piggy backing off the back pressure support, but i think that > might be too clever as it is conflating two independent

Re: WebSocket client API

> On 8 Oct 2015, at 20:51, Simone Bordet wrote: > > What it is still missing is the fact that there is no specification > about the onXXX methods regarding the lifecycle of the parameters > passed in. There is, actually. I have put it as a top-level javadoc, not as a

Re: WebSocket client API

On Fri, Oct 9, 2015 at 8:07 AM, Paul Sandoz wrote: > Hi Pavel, Simone, > > One way to make progress is to get the basic shape of the API agreed on > without flow/resource management features. That probably represented the > simplest form. I think we are very close to

Re: WebSocket client API

Hi Pavel, Simone, One way to make progress is to get the basic shape of the API agreed on without flow/resource management features. That probably represented the simplest form. I think we are very close to that. Then lets iterate from that form and consider the additional features

Re: WebSocket client API

Hi, On Tue, Oct 6, 2015 at 12:27 PM, Pavel Rappo wrote: > Hi, > > Here's an update on the WebSocket API. This iteration tries to address all > issues have been discussed so far: > >webrev: http://cr.openjdk.java.net/~prappo/8087113/webrev.01/ >javadoc:

Re: WebSocket client API

> [1] https://bugs.openjdk.java.net/browse/JDK-8138949; >That doesn't mean the default implementation won't support >'permessage-deflate'. > > -Pavel > >> On 31 Aug 2015, at 15:30, Pavel Rappo <pavel.ra...@oracle.com> wrote: >> >> Hi, >>

Re: WebSocket client API

: > > Hi, > > I would appreciate if you help to review a WebSocket client API proposed for > JDK 9. This work is a part of JEP-110 [1] and has started its public path with > HTTP client review in March this year [2]. > > Proposed WebSocket API is relatively small a

Re: WebSocket client API

Decided to take a stab at a list of "requirements"... What do people want from a WebSocket client? First, the baseline requirements: (If you don't provide 100% of this list you have a inadequate implementation): Initiate a connection - simple connect (URI) - advanced connect

Re: WebSocket client API

Hi, On Fri, Sep 11, 2015 at 12:28 PM, Pavel Rappo wrote: > Outgoing has several purposes. First of all, it separates construction of data > from sending data. Indeed, if we remove it, WebSocket will have to have many > different sendAsync variants. > Secondly it hides the

Re: WebSocket client API

Hi Richard, thanks a lot for having a look at this. > On 11 Sep 2015, at 00:41, Richard Warburton > wrote: > > Thanks a lot for implementing this by the way - I can see that it would be a > useful API for many people. That's the main problem (as usual though).

Re: WebSocket client API

Hi gents, I finally got around to looking a bit over the websocket client API proposal and have a few API feedback thoughts/suggestions. Thanks a lot for implementing this by the way - I can see that it would be a useful API for many people. 1. Consistency. It feels a bit inconsistent

Re: WebSocket client API

Hi Simone, thanks. I'm currently looking into this. > On 8 Sep 2015, at 21:18, Simone Bordet wrote: > > Hi, > > On Tue, Sep 8, 2015 at 8:34 PM, Pavel Rappo wrote: >> Hi Simone, thanks for looking at this! >> >>> On 8 Sep 2015, at 17:29, Simone

Re: WebSocket client API

On 03/09/15 09:28, Andrej Golovnin wrote: Hi Michael, Can you explain why you need j.n.Proxy rather than the String/InetSocketAddress combination proposed for HttpClient? String is not type safe. And allowing to define proxy only for the specific protocol is not enough from my experience.

Re: WebSocket client API

Hi Simone, thanks for looking at this! > On 8 Sep 2015, at 17:29, Simone Bordet wrote: > > Uh, please no. > > JDK 9 will like ship juc.Flow, so I would recommend to base on that > API rather than reinventing a new API every time to do backpressure. 1. To be honest, I

Re: WebSocket client API

Hi, On Tue, Sep 8, 2015 at 8:34 PM, Pavel Rappo wrote: > Hi Simone, thanks for looking at this! > >> On 8 Sep 2015, at 17:29, Simone Bordet wrote: >> >> Uh, please no. >> >> JDK 9 will like ship juc.Flow, so I would recommend to base on that >>

Re: WebSocket client API

Hi, On Tue, Sep 1, 2015 at 10:45 PM, Pavel Rappo wrote: > That's a very good question. The only way sending could be "back pressured" in > the current API is by blocking completion of the returned > CompletableFuture. But given the intention to provide a fully >

Re: WebSocket client API

On 08/09/15 17:29, Simone Bordet wrote: Where is TLS support ? Let's not make the same mistake already done in javax.websocket :) Thanks ! I notice it doesn't say so explicitly but "wss" urls are supported, and the relevant configuration comes from the HttpClient that the WebSocket belongs

Re: WebSocket client API

> On 8 Sep 2015, at 18:27, Michael McMahon wrote: > > On 08/09/15 17:29, Simone Bordet wrote: >> Where is TLS support ? Let's not make the same mistake already done in >> javax.websocket :) Thanks ! > > I notice it doesn't say so explicitly but "wss" urls are

Re: WebSocket client API

Hi Chris, >>> Will adding the ability to send ping(ByteBuffer) be sufficient for your >>> usage? If so, then I think we should add it, but not pong. The >>> implementation will automatically send a pong message in response to >>> receiving a ping. OK? >> >> Yes, ping(ByteBuffer) is sufficient

Re: WebSocket client API

Hi Pavel, >> - WebSocket.onClose() should contain the close reason code. > > What is it useful for? Is it ok to provide it as a part of description? > > String description = char code + ": " + String reason > Please don't do that! We definitely don't want to parse it. What we need is a

Re: WebSocket client API

Hi Michael, > Can you explain why you need j.n.Proxy rather than the > String/InetSocketAddress > combination proposed for HttpClient? String is not type safe. And allowing to define proxy only for the specific protocol is not enough from my experience. Sometimes you have to choose proxy based

Re: WebSocket client API

Hi Pavel, > So you need the ability to send pings and unsolicited pongs. Do you handle > pong > replies from the server? If so, do you control their arrival times and their > consistency with previous pings sent? What about unsolicited pongs from the > server? We use pings to ensure that

Re: WebSocket client API

Hi Chris, > Will adding the ability to send ping(ByteBuffer) be sufficient for your > usage? If so, then I think we should add it, but not pong. The > implementation will automatically send a pong message in response to > receiving a ping. OK? Yes, ping(ByteBuffer) is sufficient for us.

Re: WebSocket client API

On 3 Sep 2015, at 10:13, Andrej Golovnin wrote: > Hi Pavel, > >> So you need the ability to send pings and unsolicited pongs. Do you handle >> pong >> replies from the server? If so, do you control their arrival times and their >> consistency with previous pings

Re: WebSocket client API

On 3 Sep 2015, at 11:49, Andrej Golovnin wrote: > Hi Chris, > >> Will adding the ability to send ping(ByteBuffer) be sufficient for your >> usage? If so, then I think we should add it, but not pong. The >> implementation will automatically send a pong message in

Re: WebSocket client API

Hi Andrej, thanks for your reply! > On 2 Sep 2015, at 21:17, Andrej Golovnin wrote: > > Just because you don’t see usages for it, it does not mean that others don’t > need > it. I couldn't agree more. That's the main reasons we have this review. To tease out things

Re: WebSocket client API

On 02/09/15 21:17, Andrej Golovnin wrote: Hi Pavel, - Where's the .ping() or .pong() ? * @apiNote Keep-alive features of WebSocket protocol are taken care of * completely by implementations and are not exposed in this API. We thought that a high-level API could live without this burden for

Re: WebSocket client API

Hi Pavel, >> - Where's the .ping() or .pong() ? > > * @apiNote Keep-alive features of WebSocket protocol are taken care of > * completely by implementations and are not exposed in this API. > > We thought that a high-level API could live without this burden for the user. > At > the same time

Re: WebSocket client API

Hi Roger, thanks for looking at this! > On 1 Sep 2015, at 17:05, Roger Riggs wrote: > > - The Incoming class combines separate functions that would be easier to > use if the methods were directly on the Builder. ... > |WebSocket ws =

Re: WebSocket client API

Hi Joakim, First of all, thank you so much for such a comprehensive list of questions! I'll try to answer them to the best of my knowledge. But before, I need to clarify one thing. I've noticed many of the questions are about lack of some advanced features in the API. Well, they are for sure

Re: WebSocket client API

1/2015 10:30 AM, Pavel Rappo wrote: Hi, I would appreciate if you help to review a WebSocket client API proposed for JDK 9. This work is a part of JEP-110 [1] and has started its public path with HTTP client review in March this year [2]. Proposed WebSocket API is relatively small and focuses on

Re: WebSocket client API

veloper feedback? or encouraged based on guidelines for java, the JDK, or classlib? can alternate APIs be proposed still? - Joakim Erdfelt Eclipse/Jetty WebSocket Implementor On Mon, Aug 31, 2015 at 7:30 AM, Pavel Rappo <pavel.ra...@oracle.com> wrote: > Hi, > > I would appreciate if you he

WebSocket client API

Hi, I would appreciate if you help to review a WebSocket client API proposed for JDK 9. This work is a part of JEP-110 [1] and has started its public path with HTTP client review in March this year [2]. Proposed WebSocket API is relatively small and focuses on convenient exchange of data