Improve modularity around client/server split

[glassfishrobot]

As of draft 12 there are two jars named "javax.websocket-api" (aka server) and "javax.websocket-client-api". As in draft 11 there is a server sub-package with all other classes (common and client) being in the top level package. I understand most implementations are expected to implement client and server API, while it's also possible for a library to implement client side only. However, things look pretty confusing to someone not familiar with that implicit expectation.

Given "javax.websocket-client-api", one would expect "javax.websocket-server-api" with shared functionality in "-common" or "-core". This does mean one extra module but that makes more sense from an application perspective at runtime. If I'm writing a server-only application I need to depend on server and common whereas currently I'd have to depend on server and client with client being included only because I need the common (and not the client) classes.

Similarly it would greatly help in understanding the API if there was a client package just like there is a server package. It's very easy to recognize the 6 server-specific classes but the top level package contains 25 classes and it's not easy to make out which ones are shared and which ones are client specific. To look at it from another perspective, if there is a server package why shouldn't there be a client package?

[glassfishrobot]

@glassfishrobot Commented
Reported by rstoyanchev

[glassfishrobot]

@glassfishrobot Commented
Was assigned to jitu

[glassfishrobot]

@glassfishrobot Commented
rstoyanchev said:
I see now that mvn install bundles all classes in "javax.websocket-api", which means I should be able to get all classes from it. However, the .pom still shows a transitive dependency on "javax-.websocket-client-api", which means I'll end up with two jars, unless I explicitly exclude "javax-.websocket-client-api". Is this an error? Also the "javax.websocket-api" sources jar contains only server classes, which is inconsistent.

[glassfishrobot]

@glassfishrobot Commented
jitu said:
I am aware that the javax.websocket-api-sources.jar needs to fixed.

But isn't it ok for javax.websocket-api.jar to have a dependency on javax.websocket-client-api.jar ? Where are you facing the problem with two jars ?

[glassfishrobot]

@glassfishrobot Commented
rstoyanchev said:

But isn't it ok for javax.websocket-api.jar to have a dependency on javax.websocket-client-api.jar ?

It's confusing if nothing else but it could potentially lead to issues in the future when there is more than one version of the websocket api.

[glassfishrobot]

@glassfishrobot Commented
dannycoward said:
The split we want here is that we have two profiles

one that runs on web servers
one that runs on desktop machines

The client/server terminology is explained in the spec document, but a websocket client is one that only initiates connections, a websocket server is one that accepts connections.

The first profile needs to do both (the expert group wants websockets on a web server to be able to accept connections and initiate them). The second profile only needs to have 'client' functionality (the expert group wanted the desktop profile to initiate connections but not accept them). If only the web server didn't have 'client' functionality it would all be easier !

The javax.websocket package is everything in common to both profiles. The javax.websocket.server package is everything that only applies to websockets in web servers.

So we have the right split of packages/classes for the two profiles. We will always version them the same, and release updates simultaneously.

Would it help to call the JAR files something different ? javax.websocket-web and javax.websocket-client ?

Danny

[glassfishrobot]

@glassfishrobot Commented
rstoyanchev said:
Sorry for not responding sooner. I think the names are fine. It looks like the intent for javax.websocket-api is to contain all necessary files for both client and server but its pom indicates a dependency on javax.websocket-client, which technically is not needed since javax.websocket-api already contains all the files. This arrangement is a bit odd but not a show stopper. Feel free to close this issue.

[glassfishrobot]

@glassfishrobot Commented
dannycoward said:
OK thanks Rossen for taking a close look here. Closing this one out.

[glassfishrobot]

@glassfishrobot Commented
Marked as fixed on Thursday, February 28th 2013, 12:50:55 pm

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA WEBSOCKET_SPEC-135

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/websocket-spec/issues/135
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @pavelbucek
• Original Issue Closed By:@glassfishrobot