[WEBSOCKET_SPEC-30] API suggestions pot pourri Created: 12/Oct/12  Updated: 14/Dec/12  Resolved: 14/Dec/12

Status: Resolved
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dannycoward Assignee: dannycoward
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: v010

 Description   

API:

  • perhaps Endpoint could have a method returning a set of currently open sessions or for broadcasting messages to all open sessions for a given endpoint?
  • Decoders/Encoders - seems there are too many variants of decoders/encoders (binary stream, text stream, binary, text) - can't we simply go with streaming and provide default implicit decoders for Stream<>String and Stream<>byte[] and whatever other types we want to support?
  • too many MessageHandler classes. Why can't we simply have MessageHandler<T>, PartialMessageHandler<T> and PongHandler and decide based on the type argument which message handler should be called for a given message?
  • for async operations, no way to specify timeouts?
  • why is RemoteEndpoint capable of sending only one type of object? Why can't it simply have a single <M> send(M message) method for sending objects of any kind instead of having sendString(), sendObject(), sendBytes() and getSendStream()?
  • There is no notion of path params in programmatic API, DefaultServerConfiguration.matchUri() only supports exact match, but annotations support path template matching? That does not seem right.
  • should ServerContainer.publishServer() be renamed to publishEndpoint()? Since that's what it seems to do.
  • Session should have methods for retrieving path parameters and property bag for storing session-related data
  • nitpick - in the Endpoint, session param should come first in onError to make it more consistent with onOpen and onClose


 Comments   
Comment by dannycoward [ 14/Dec/12 ]

All these issues are resolved or already tracked.
perhaps Endpoint could have a method returning a set of currently open sessions or for broadcasting messages to all open sessions for a given endpoint?
(already issue for this.)
Decoders/Encoders - seems there are too many variants of decoders/encoders (binary stream, text stream, binary, text) - can't we simply go with streaming and provide default implicit decoders for Stream<>String and Stream<>byte[] and whatever other types we want to support?
(Will not change this, two modes explicitly requested.)

too many MessageHandler classes. Why can't we simply have MessageHandler<T>, PartialMessageHandler<T> and PongHandler and decide based on the type argument which message handler should be called for a given message?
(fixed in v008)
for async operations, no way to specify timeouts?
(already an issue for this)
why is RemoteEndpoint capable of sending only one type of object? Why can't it simply have a single <M> send(M message) method for sending objects of any kind instead of having sendString(), sendObject(), sendBytes() and getSendStream()?
(We are balancing usability with abstractness)
There is no notion of path params in programmatic API, DefaultServerConfiguration.matchUri() only supports exact match, but annotations support path template matching? That does not seem right.
(this is now in)
should ServerContainer.publishServer() be renamed to publishEndpoint()? Since that's what it seems to do.
(v010 has a new deployment mechanism, this method no longer exists)
<done>
Session should have methods for retrieving path parameters and property bag for storing session-related data
nitpick - in the Endpoint, session param should come first in onError to make it more consistent with onOpen and onClose
(now consistent)

Generated at Wed Mar 04 11:53:06 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.