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) {
>
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 that you proposed a while ba
> 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 implementing interfaces A and B
> 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
> 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 possibly more methods
and
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 it may even be wrong).
>
> 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 like you've said. And we're
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 implement
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 b
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 14:37, Joakim Erdfelt
>
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 take the raw bytes (presuma
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
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.
>> CharBuffer is a way to obtain char (the 2 byte
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 ByteBuffer or String you c
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.
On 10/20/2015 12:49 PM, Simone Bordet wrote:
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
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 be:
>
> CompletionStage
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 user
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)
http://tools.ietf.org/html/rfc6455#secti
Hi,
On Sat, Oct 17, 2015 at 8:56 PM, Pavel Rappo wrote:
>>> * WebSocket has become an abstract class
>>
>> What is the rationale behind this ?
>> Just to avoid subclassing ?
>> Why subclassing is negated ?
>> I think it's best it remains an interface: it would allow people to
>> write wrappers,
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 means
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
>
> Relying on the JVM bui
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
> to use.
> > Below my fee
> 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/
>> javadoc: http://cr.openjdk.java.net/~prappo/808
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: http://cr.openjdk.java.net/~prappo/8087113/webrev.02/
> javadoc: http:
Hi,
Here's a second update on the WebSocket API:
webrev: http://cr.openjdk.java.net/~prappo/8087113/webrev.02/
javadoc: http://cr.openjdk.java.net/~prappo/8087113/javadoc.02/
Main differences from the previous version:
* WebSocket has become an abstract class
* New methods in Builder: h
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 intern
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 payload
> as a ByteBuffer
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 mechanism for managing buffers used by Listener.
I thi
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 be an actual javadoc):
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, (_, failure) -> {});
>> }
>
> That would only surpri
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 actions. I have a
> hunch
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 that.
>
> Then lets iterate f
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
(back-press
> 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 javadoc to
each single meth
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: http://cr.openjdk.java.net/~prappo/8
Hi,
Overall i think this API seems to be compressing down nicely to a small number
of classes/interfaces, but i still think there is some room for further
simplifications.
WebSocket
I don’t see the need for a context parameter. Context can be obtained via
capturing. That reduces the requirem
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: http://cr.openjdk.java.net/~prappo/8087113/javadoc.01/
Main differences from the previous version:
*
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 (HttpClien
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 notion of fragmentation.
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). Different people have different
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 that the "s
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 Bordet wrote:
>>>
>>> Uh, please no.
>>>
>>> J
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
>> API rather than reinventing a new API every time to
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 don't think Flow API is a
> 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 supported, and the
> relevant co
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 t
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
> asynchronous
> non-blocking 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. Some
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
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 m
Hi Pavel,
On 9/2/2015 4:40 PM, Pavel Rappo wrote:
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 = WebSocket.new
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 response to
>> receiving a p
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.
Best
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 sent? What about unsolicited pon
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 firewal
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 on
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 we've completely forgotten,
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 th
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 = WebSocket.newBuilder("ws://websocket.example.com")
> .onRec
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 th
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
nego
Hi Pavel,
A few comments on the API:
- The Incoming class combines separate functions that would be easier to
use if the methods were directly on the Builder. It would also
allow (not require)
lambda's to be used or method references if the code was complex.
The Builder methods can
java.net.WebSocket
In general, I like the simpler approach that JEP110 is taking (over how
javax.websocket and JSR356 did it)
(MessageHandlers, Configurators, Decoders, and Encoders, oh my!)
Here's my first pass through the javadoc and JEP110 (with a focus on
WebSocket)
Upgrade:
- There's 2 w
64 matches
Mail list logo
