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-pressure and resource management), see how they fit or push/pull the basic shape in various directions, and importantly see what additional demands are imposed on the developer. Also, I expect those features would need to be co-ordinated somewhat with the HTTP API to ensure a common pattern and possibly reuse of certain types. -- Regarding back pressure, i like what Michael/Pavel did with LongConsumer. 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 that to do this effectively we may need some sort of resource supplier that is registered with the builder. That supplier defines the resource management strategy and requirements on a listener consuming resources (that is somewhat annoying because it couples the resource supplier with the listener). Paul. > On 9 Oct 2015, at 15:18, Pavel Rappo <pavel.ra...@oracle.com> wrote: > > >> On 8 Oct 2015, at 20:51, Simone Bordet <simone.bor...@gmail.com> 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 method. But that's an editorial problem, not a spec one. > > 1. Go to: > http://cr.openjdk.java.net/~prappo/8087113/webrev.01/raw_files/new/src/java.httpclient/share/classes/java/net/httpclient/WebSocket.java > 2. Look for occurrences of "reuse". There are exactly 2 of them :-) > >> For example, this is going to surprise users (simple echo): >> >> onBinary((ws, bytes, last) -> { >> ws.sendBinary(bytes, last, null, (_, failure) -> {}); >> } > > That would only surprise people who don't read javadoc. Or you > want to say it's an inherently bad decision to allow people to > reuse implementation's ByteBuffer? > >> It's not going to work because the send is async, and there is no >> specification about who owns the ByteBuffer "bytes". >> In my experience, it is bad to force applications to perform a copy >> (not to mention that the copy could be really expensive, as WebSocket >> frames could be large). > > I wonder what percentage of use cases this scenario corresponds to? Namely, a > huge payload being received, transformed(?) and sent on the WebSocket. I ask > this because I have to understand whether the added complexity worth the value > provided by the functionality. > >> This would also lead to applications being forced to block waiting for >> the send to complete > > How come? Send is not blocking. Unless one performs a rather odd thing: will > block on handler completion before returning an onXXX call. > >> StatusCode makes little sense to me: it's a wrapper for int, and >> nothing more. I would prefer to see primitive int in the signatures. > > Type safety, having documentation in a single place, maybe richer string > representation (toString)? > >> Method isClosed() does not convey enough information. >> WebSocket has built-in in the protocol half-closes, so it should be >> able to report this information, like Socket returns >> isInputShutDown(), isOutputShutDown() and isOpen(). >> A simple enum would do. > > What's the use case other than debugging? > >> I think it's enough for the builder to provide an async build() method only. > > Makes sense. >
signature.asc
Description: Message signed with OpenPGP using GPGMail
