> On 20 Feb 2018, at 23:49, Simone Bordet wrote:
>
> I don't see why the message should be reassembled, given
> MessagePart.[FIRST|PART|LAST] ?
> It's not that the user can ask for the kind of MessagePart, e.g. ask
> only for WHOLE messages that the implementation must reassemble on her
> behalf
> On 20 Feb 2018, at 20:49, Simone Bordet wrote:
>
> Hi,
>
> On Tue, Feb 20, 2018 at 9:35 PM, Chris Hegarty
> wrote:
>> Optimistically, if the whole message is read from the underlying
>> socket in one native read ( small messages ), then the whole
>> message will be in a single byte buffer,
Hi,
On Tue, Feb 20, 2018 at 9:35 PM, Chris Hegarty wrote:
> Optimistically, if the whole message is read from the underlying
> socket in one native read ( small messages ), then the whole
> message will be in a single byte buffer, zero copy.
Good.
> If not, then to re-assemble the whole message
Simone,
> On 20 Feb 2018, at 20:19, Simone Bordet wrote:
>
> Hi,
>
> On Tue, Feb 20, 2018 at 8:35 PM, Pavel Rappo wrote:
>> If by copies you mean allocating new buffers and feeling them with the same
>> contents, then you are right. No copies are made.
>
> I mean that you call user code with
Hi,
On Tue, Feb 20, 2018 at 8:35 PM, Pavel Rappo wrote:
> If by copies you mean allocating new buffers and feeling them with the same
> contents, then you are right. No copies are made.
I mean that you call user code with a ByteBuffer produced from a
slice() of an internal ByteBuffer.
The CF me
Thanks Simone,
I think this is a good example of how this low-level API can be
leveraged to build adapters, InputStream in this case. Equally,
that could be a RS Subscriber, or some other non-blocking
async JSON parser, or something else.
Let’s not get caught up in what the JDK should provide
out
> On 20 Feb 2018, at 21:31, Simone Bordet wrote:
>
>
>
> This version has the advantage that guarantees that no other copy is
> done, not even by the implementation (hopefully, right Pavel ?), while
> with JDK 8 there may have been hidden copies to provide a full
> ByteBuffer.
>
If by copi
Thank you so much for your assistance, Simone.
On Tue, Feb 20, 2018 at 10:31 AM, Simone Bordet
wrote:
> Hi,
>
> On Tue, Feb 20, 2018 at 4:32 PM, Chuck Davis wrote:
> > Simone, please, please tell me how this is done.
>
>
> This version has the advantage that guarantees that no other copy is
> d
Hi,
On Tue, Feb 20, 2018 at 4:32 PM, Chuck Davis wrote:
> Simone, please, please tell me how this is done.
The WebSocket.Listener APIs return a CompletableFuture, indicating
when the application is done with the processing of the parameters
passed to the listener method (in particular the ByteBu
> ByteBufferInputStream bbis = new ByteBufferInputStream();
> for each partial ByteBuffer received by the listener {
> bbis.add(byteBuffer);
> }
> ois = new ObjectInputStream(bbis);
> MyDTO = ois.readObject();
>
> Now, ByteBufferInputStream is not present in the JDK, and if you want
> to complain
The conversation has gone a little off topic from the WebSocket API,
and this is probably not the best place to be discussing such proposed
convenience / performance APIs, since they need broader discussion
than net-dev.
It seems most folk are in agreement that the proposed WebSocket API
could be
Hi,
On Tue, Feb 20, 2018 at 10:22 AM, Alan Bateman wrote:
>
>
> On 20/02/2018 08:14, Simone Bordet wrote:
>>
>> :
>> Where would be a good list to start discussing ByteBuffer to
>> [Input|Output]Stream bridging ?
>>
> Are you looking for this for performance or convenience reasons?
Convenience.
On 20/02/2018 08:14, Simone Bordet wrote:
:
Where would be a good list to start discussing ByteBuffer to
[Input|Output]Stream bridging ?
Are you looking for this for performance or convenience reasons?
Bridging channel and input/output streams is natural of course, bridging
between buffers a
Alan,
On Tue, Feb 20, 2018 at 8:50 AM, Alan Bateman wrote:
> On 19/02/2018 20:19, Simone Bordet wrote:
>>
>> :
>> Now, ByteBufferInputStream is not present in the JDK, and if you want
>> to complain you are in good (and conspicuous) company, as the JDK
>> engineers appear to avoid the issue since
On 19/02/2018 20:19, Simone Bordet wrote:
:
Now, ByteBufferInputStream is not present in the JDK, and if you want
to complain you are in good (and conspicuous) company, as the JDK
engineers appear to avoid the issue since years now (e.g. create a
String from a ByteBuffer without copy).
There is
Hi,
On Mon, Feb 19, 2018 at 10:55 PM, Chuck Davis wrote:
>> Note also that your requirement is to use blocking, stream-based,
>> byte[]-based APIs.
>> If you had chosen a data format for which a non-blocking parser based
>> on ByteBuffer APIs existed, you would be so happy about the JDK 9
>> APIs
Hi Simone:
Thanks for jumping in with your thoughts.
On Mon, Feb 19, 2018 at 12:19 PM, Simone Bordet
wrote:
> Hi,
>
> Well, not so fast.
> There are a lot of assumptions in the above code.
> The first is that the ByteBuffer has a backing array, which may not be the
> case.
> If you write the ri
Hi,
On Sun, Feb 18, 2018 at 9:12 PM, Chuck Davis wrote:
> There is a great hush here regarding strategy for putting the pieces
> back together so here goes my tirade.
>
> Following is based on assumption of a 100k payload.
>
> With jdk8:
> The decoder received a ByteBuffer
> bais = new ByteArrayI
Further thought...
Maybe a single WebSocket but two different listeners the developer can
choose depending upon what type of stream is expected???
Hi Chris and others:
There is only one WebSocket documented in jdk9. I was happy to be able to
write a jdk9 client that connected to my server unchanged (using
Wildfly11). And there are features of jdk9 API that I rather like.
There are two vastly differing handling requirements. I certainly a
On 18/02/18 20:12, Chuck Davis wrote:
...
RESULT: The formerly fabulous WebSocket has been rendered relatively
useless as a platform for building responsive, bidirectional
client/server applications. Am I the only person who sees this as a
HUGE regression of functionality?? I am ALARMED by t
James, who taught you how to ruin other people's days? You seem to have
mastered the art..😐
There seems to be a move afoot to abandon serialization.hummm. Then it
needs to get fixed because converting everything to a text stream before
transmitting is not an option (for me at least). Th
Hi Chuck,
Let's just imagine that for a moment that there existed a reactive streams
equivalent to an ObjectReader (there isn't, and there's good reason why
there isn't, but I'll get to that later). Then, the code would be something
like this (the Source API there is an Akka Streams like API):
Ht
There is a great hush here regarding strategy for putting the pieces
back together so here goes my tirade.
Following is based on assumption of a 100k payload.
With jdk8:
The decoder received a ByteBuffer
bais = new ByteArrayInputStream(ByteBuffer.array()); // wrap the
buffer -- optional method b
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
88 matches
Mail list logo
