Hi gents, I finally got around to looking a bit over the websocket client API proposal and have a few API feedback thoughts/suggestions. Thanks a lot for implementing this by the way - I can see that it would be a useful API for many people.
1. Consistency. It feels a bit inconsistent that the "start builder" method name for HttpClient is create() and "end builder" method name is "build", whereas for websockets the start is "newBuilder" and the end is "create". This is because a. that they're different, and b. that create() is the start for one, and the end for the other. 2. I like the use of CompletableFutures in the API. 3. Perhaps I'm missing something here, but I don't see the value of the "Outgoing" abstraction. It seems like it would be simpler and lower allocation to just having multiple sendAsync methods, whilst the outgoing class adds unnecessary complexity to the API. 4. In a similar vein requiring API users who are consuming data to extend the Incoming class also seems to be a negative. An alternative would be to offer the ability to register multiple callbacks with functional interfaces for receiving data. The advantage of this approach is that it means that users of the API don't have to force their class hierachy to fit into the API. They can just write it independently and use method references or lambdas to wire up the callbacks for receiving data. Hope this is helpful and best of luck with it all. regards, Richard Warburton http://insightfullogic.com @RichardWarburto <http://twitter.com/richardwarburto>
