Hi folks,
You'll remember we simplified the package naming to javax.websocket.*
right after EDR when we were still exploring the requirements on the
client api (see below), with the ultimate goal of a clean separation
between APIs that run on the client side and APIs that run on the server
side.
Now that the dust has settled on that, and that we have determined that
we want websocket server implementations to be able to act as clients
(that is to say, initiate connections to websocket peers, in addition to
awaiting connections from peers), it seems clear that the two 'profiles'
of websocket are core APIs + client, and core APIs + client + server
only APIs.
To that end, I'm proposing one last change to the package structure to
reflect this:-
javax.websocket.* - for all core APIs, and client functionality
javax.websocket.server.* - for functionality specific only to the server
That way, the client 'profile' of websockets is (javax.websocket.*), and
it contains only and all APIs needed for the client side, i.e. for rich
client applications. The server 'profile' of websockets is
(javax.websocket.* + javax.websocket.server.*) and contains all the APIs
needed for server applications.
This is what the API would look like in this (final?) package structure:-
javax.websocket.server.*
- DefaultServerEndpointConfiguration
- ServerEndpointConfiguration
- ServerContainer
- WebSocketEndpoint
- WebSocketPathParam
javax.websocket.*
-<everything else>
Let me know if anyone sees any issues with this arrangement.
- Danny
On 11/7/12 5:59 PM, Danny Coward wrote:
> Hi folks,
>
> Some other feedback I've consistently had was to look again at the
> package naming. Currently we have
>
> javax.net.websocket - core APIs
> javax.net.websocket.annotations - annotations
> javax.net.websocket.extensions - extension SPI
>
> One feedback has been: use javax.websocket.* instead of
> javax.net.websocket. The original rationale for javax.net.websocket
> was that websocket is a network protocol, so should live under
> java.net. But javax.websocket is consistent with the web service
> specs, servlet etc.
>
> So I think we should make that change.
>
> Secondly, I put annotations subpackage there so that it would clearly
> separate the API classes from the annotations, for the sake of making
> the spec easier to review and understand. But the common practice for
> APIs seems to be to put annotations in with API classes. So I think we
> should move the annotations into the core too.
>
> Depending on how we see the client API, we may need to split the API
> such that we have a separate client-only and server-only packages, but
> apart from that change, I would like to move ahead with these proposed
> changes to the package naming.
>
> Please let me know if you see any issues with that approach.
>
> And that's it for today. I know we have a lot of issues on the list
> right now, I will do a summary of all the open issues later this week
> so if you are not following everything, you can jump back aboard.
>
> Cheers,
>
> - Danny
>
>
>
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation