some comments on the specification (catching up, so ignore what have
already been discussed in the list :-))
- Section 3.1.5 "In particular, they may wish to intervene more
in the handshake process. For example,
they may wish to use Http cookies to track clients, or insert
application speciﬁc headers
in the handshake response"
header after an hanshake. So I'm sure sure allowing an
application to do that is the right way to go.
- Section 4.2: "The decorated method must either have no
parameters or have a single parameter that is a Session object."
to set any custom header, this is still possible to pass query
strings to the URL. Hence it would be convenient to be able to
see the Request information from an onOpen method.
we should support getQueryString/getParams etc. on the
- Section 4.2.1 : "The decorated method must either have no
parameters or have a single parameter that is a Session
- getCloseReason on Session doesn't looks corect. What will be
the returned value when the session is active? I think the
CloseReason should be passed to the @WebSocketClose method
instead of being intermixed with the session API.
In general all the APIs aren't fluid and never return itself ... for
example, the Session interface could return itself instead of 'void'
all over the place. Would be nice to be able to chain calls
- Any reason to use RemoteEndpoint instead of WebSocket as the
class's name? I found it confusing, e.g we don't call a
RemoteSocket a Socket in java.io ;-)
- Should the HanshakeRequest by typed so getSession() returns
the type instead of Object? So we don't have to call instanceof
to make sure we are getting the right Session object at runtime.
Endpoint.onClose should pass the close closing code IMO so an
something based on a close code. Live above, I don't think
mixing close status inside the Session is the right way to go.
ClientContainer.getActiveSessions(): This needs to be clarified
as Session may become invalid at any moment.
- Do we really need the Decoder.willDecode(..) API? Should we
throw an exception instead when the decode gets called?
- Session.getMessageHandler() must return a
That's cosmetic, I know.
On 12-09-14 7:44 PM, Danny Coward
I've updated the specification document and API again this week.
I'm still looking for review comments. This week only some smaller
changes, the API tweaks arising from our work on the reference
implementation (see below).
The v005 API is in the source repository, under the v005 branch.
spec document and javadoc here:-
- added to the security chapter in the specification.
- bolstered up some of the javadoc here and there, esp annotations
- added missing constructors on DecodeException
- add WebSocketError annotation, mirroring other lifecycle
We have had a number of drafts and revisions now, and I think with
one more round of review next week and comment we are almost ready
for Expert Draft review. Many of you will know all about this
stage, but the main point is that it allows us to get review from
a wider audience. Not everything has to be finished, or complete.
But I think we have a lot of our content in place, and with
another round of review, it will be in good enough shape for new
readers to give us good feedback on what is there.
We have made the RI project public now: its at http://java.net/projects/tyrus/
if you want to take a look. Still a work in progress, but it is
tracking the v003 API.
|| Danny Coward