Issue Details (XML | Word | Printable)

Key: WEBSOCKET_SPEC-9
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Minor Minor
Assignee: dannycoward
Reporter: dannycoward
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
websocket-spec

API Usability: Consider API renaming, minor refactorizations for usability

Created: 21/Sep/12 11:11 PM   Updated: 23/Feb/13 12:03 AM   Resolved: 23/Feb/13 12:03 AM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Tags: v013
Participants: dannycoward


 Description  « Hide

In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.

Feedback: I think the Session class would be more intuitively served by calling Connection because that's what it seems to captures between the two peers. There is no message bag to store properties (no need to have it) to make this class look like a session. All other methods on this class seem more like properties of a connection rather than a session.

Split RemoteEndpoint send functionality into a handful of specialized RemoteEndpoints, each with a different mode:-

one for basic whole message sending
one for streaming message sending
one for async message sending
one for batching, which could be optional.

DefaultServerConfiguration should be DefaultServerEndpointConfiguration
ditto client config class.

private static String CLIENT_CLASSNAME_PROPERTYNAME = "websocket.clientcontainer.classname"; and WebSocketContainer.getClientContainer(). Should not need to be client specific -> getContainer() ?

IOException on client connect APIs for IO errors, deployment error would then only be for badly formed endpoints.

Annotation names: too long ? Need WebSocket in all of them ? Better distinction between client and server annotations ?

Refactor standard handshake header names into one separate util class.

ServerApplicationConfiguration should be renamed: According to the spec, there may be more than one ServerApplicationConfiguration classes in the application. In that case ServerApplicationConfiguration should be renamed to something else, as it is not application configuration. We need a name that distinguishes it from endpoint configurations, yet there may be some confusion with the name Application causing people to think there can only be one per application package, which is not true.



dannycoward made changes - 12/Oct/12 11:08 PM
Field Original Value New Value
Description In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.
In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.

Consolidate MessageHandlers and RemoteEndpoint.send methods to one or two interfaces / method sigs.
dannycoward made changes - 17/Oct/12 07:35 PM
Description In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.

Consolidate MessageHandlers and RemoteEndpoint.send methods to one or two interfaces / method sigs.
In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.

Consolidate MessageHandlers and RemoteEndpoint.send methods to one or two interfaces / method sigs.


Feedback: I think the Session class would be more intuitively served by calling Connection because that's what it seems to captures between the two peers. There is no message bag to store properties (no need to have it) to make this class look like a session. All other methods on this class seem more like properties of a connection rather than a session.
dannycoward made changes - 30/Nov/12 07:20 PM
Priority Major [ 3 ] Minor [ 4 ]
dannycoward made changes - 21/Dec/12 10:23 PM
Summary API Usability: Consider using Fluid style throughout the API, rework naming API Usability: Consider API renaming, minor refactorizations for usability
Description In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.

Consolidate MessageHandlers and RemoteEndpoint.send methods to one or two interfaces / method sigs.


Feedback: I think the Session class would be more intuitively served by calling Connection because that's what it seems to captures between the two peers. There is no message bag to store properties (no need to have it) to make this class look like a session. All other methods on this class seem more like properties of a connection rather than a session.
In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.

Feedback: I think the Session class would be more intuitively served by calling Connection because that's what it seems to captures between the two peers. There is no message bag to store properties (no need to have it) to make this class look like a session. All other methods on this class seem more like properties of a connection rather than a session.

Split RemoteEndpoint send functionality into a handful of specialized RemoteEndpoints, each with a different mode:-

one for basic whole message sending
one for streaming message sending
one for async message sending
one for batching, which could be optional.

DefaultServerConfiguration should be DefaultServerEndpointConfiguration
ditto client config class.

private static String CLIENT_CLASSNAME_PROPERTYNAME = "websocket.clientcontainer.classname"; and WebSocketContainer.getClientContainer(). Should not need to be client specific -> getContainer() ?


IOException on client connect APIs for IO errors, deployment error would then only be for badly formed endpoints.
dannycoward made changes - 21/Dec/12 10:23 PM
Description In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.

Feedback: I think the Session class would be more intuitively served by calling Connection because that's what it seems to captures between the two peers. There is no message bag to store properties (no need to have it) to make this class look like a session. All other methods on this class seem more like properties of a connection rather than a session.

Split RemoteEndpoint send functionality into a handful of specialized RemoteEndpoints, each with a different mode:-

one for basic whole message sending
one for streaming message sending
one for async message sending
one for batching, which could be optional.

DefaultServerConfiguration should be DefaultServerEndpointConfiguration
ditto client config class.

private static String CLIENT_CLASSNAME_PROPERTYNAME = "websocket.clientcontainer.classname"; and WebSocketContainer.getClientContainer(). Should not need to be client specific -> getContainer() ?


IOException on client connect APIs for IO errors, deployment error would then only be for badly formed endpoints.
In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.

Feedback: I think the Session class would be more intuitively served by calling Connection because that's what it seems to captures between the two peers. There is no message bag to store properties (no need to have it) to make this class look like a session. All other methods on this class seem more like properties of a connection rather than a session.

Split RemoteEndpoint send functionality into a handful of specialized RemoteEndpoints, each with a different mode:-

one for basic whole message sending
one for streaming message sending
one for async message sending
one for batching, which could be optional.

DefaultServerConfiguration should be DefaultServerEndpointConfiguration
ditto client config class.

private static String CLIENT_CLASSNAME_PROPERTYNAME = "websocket.clientcontainer.classname"; and WebSocketContainer.getClientContainer(). Should not need to be client specific -> getContainer() ?


IOException on client connect APIs for IO errors, deployment error would then only be for badly formed endpoints.

Annotation names: too long ? Need WebSocket in all of them ? Better distinction between client and server annotations ?
dannycoward made changes - 21/Dec/12 11:34 PM
Description In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.

Feedback: I think the Session class would be more intuitively served by calling Connection because that's what it seems to captures between the two peers. There is no message bag to store properties (no need to have it) to make this class look like a session. All other methods on this class seem more like properties of a connection rather than a session.

Split RemoteEndpoint send functionality into a handful of specialized RemoteEndpoints, each with a different mode:-

one for basic whole message sending
one for streaming message sending
one for async message sending
one for batching, which could be optional.

DefaultServerConfiguration should be DefaultServerEndpointConfiguration
ditto client config class.

private static String CLIENT_CLASSNAME_PROPERTYNAME = "websocket.clientcontainer.classname"; and WebSocketContainer.getClientContainer(). Should not need to be client specific -> getContainer() ?


IOException on client connect APIs for IO errors, deployment error would then only be for badly formed endpoints.

Annotation names: too long ? Need WebSocket in all of them ? Better distinction between client and server annotations ?
In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.

Feedback: I think the Session class would be more intuitively served by calling Connection because that's what it seems to captures between the two peers. There is no message bag to store properties (no need to have it) to make this class look like a session. All other methods on this class seem more like properties of a connection rather than a session.

Split RemoteEndpoint send functionality into a handful of specialized RemoteEndpoints, each with a different mode:-

one for basic whole message sending
one for streaming message sending
one for async message sending
one for batching, which could be optional.

DefaultServerConfiguration should be DefaultServerEndpointConfiguration
ditto client config class.

private static String CLIENT_CLASSNAME_PROPERTYNAME = "websocket.clientcontainer.classname"; and WebSocketContainer.getClientContainer(). Should not need to be client specific -> getContainer() ?


IOException on client connect APIs for IO errors, deployment error would then only be for badly formed endpoints.

Annotation names: too long ? Need WebSocket in all of them ? Better distinction between client and server annotations ?

Refactor standard handshake headers into one separate util class
dannycoward made changes - 08/Feb/13 11:43 PM
Description In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.

Feedback: I think the Session class would be more intuitively served by calling Connection because that's what it seems to captures between the two peers. There is no message bag to store properties (no need to have it) to make this class look like a session. All other methods on this class seem more like properties of a connection rather than a session.

Split RemoteEndpoint send functionality into a handful of specialized RemoteEndpoints, each with a different mode:-

one for basic whole message sending
one for streaming message sending
one for async message sending
one for batching, which could be optional.

DefaultServerConfiguration should be DefaultServerEndpointConfiguration
ditto client config class.

private static String CLIENT_CLASSNAME_PROPERTYNAME = "websocket.clientcontainer.classname"; and WebSocketContainer.getClientContainer(). Should not need to be client specific -> getContainer() ?


IOException on client connect APIs for IO errors, deployment error would then only be for badly formed endpoints.

Annotation names: too long ? Need WebSocket in all of them ? Better distinction between client and server annotations ?

Refactor standard handshake headers into one separate util class
In particular, Session and FrameBuilder, configurations.

RemoteEndpoint/Peer/WebSocket

Annotations have long names.

Session is perhaps too general. Session/WebSocketSession/Connection/Conversation.

Feedback: I think the Session class would be more intuitively served by calling Connection because that's what it seems to captures between the two peers. There is no message bag to store properties (no need to have it) to make this class look like a session. All other methods on this class seem more like properties of a connection rather than a session.

Split RemoteEndpoint send functionality into a handful of specialized RemoteEndpoints, each with a different mode:-

one for basic whole message sending
one for streaming message sending
one for async message sending
one for batching, which could be optional.

DefaultServerConfiguration should be DefaultServerEndpointConfiguration
ditto client config class.

private static String CLIENT_CLASSNAME_PROPERTYNAME = "websocket.clientcontainer.classname"; and WebSocketContainer.getClientContainer(). Should not need to be client specific -> getContainer() ?


IOException on client connect APIs for IO errors, deployment error would then only be for badly formed endpoints.

Annotation names: too long ? Need WebSocket in all of them ? Better distinction between client and server annotations ?

Refactor standard handshake header names into one separate util class.

ServerApplicationConfiguration should be renamed: According to the spec, there may be more than one ServerApplicationConfiguration classes in the application. In that case ServerApplicationConfiguration should be renamed to something else, as it is not application configuration. We need a name that distinguishes it from endpoint configurations, yet there may be some confusion with the name *Application* causing people to think there can only be one per application package, which is not true.
dannycoward added a comment - 23/Feb/13 12:03 AM

Some of these have been fixed in v013, some will not be fixed. Here's a tally of what changed

Annotations have been renamed to address the name length and client/server distinction.
RemoteEndpoint has been refactored
Session is the same
The configuration API has changed, plus there is a separate issue tracking some suggestions for renames on the new API
Client connect APIs now include IOException and DeploymentException
ContainerProvider now uses the ServiceLoader mechanism, not a system property


dannycoward made changes - 23/Feb/13 12:03 AM
Status Open [ 1 ] Resolved [ 5 ]
Assignee dannycoward [ dannycoward ]
Tags v013
Resolution Fixed [ 1 ]