OK, so what I'm hearing is we'll drop the extensions, but we're
reluctant to defer the client APi to the next relesase.
So let me check on what we mean by 'client implementation' before we add
what's missing to the API and what kind of separation of packaging we
would need.
By client implementation we mean a something that runs on the JDK and
takes the place of a websocket enabled browser in interacting with
websocket endpoint deployed on a server. So the client implementation
allows developers to deploy endpoints that connect to a server, send and
receive web socket messages one the connection is made. But it doesn't
publish web socket endpoints for other web socket clients to connect
to. (this is how I am seeing it currently)
Would you expect the web container to support this client API as well ?
i.e. do you think that web containers will initiate web socket
connections to other web socket peers ? (I'm thinking this is not really
a central use case).
- Danny
On 11/3/12 6:37 AM, Justin Lee wrote:
> Personally, i think the client API would be a bad idea to drop. We
> could probably live without it but it'd be nice to have especially for
> symmetry with the http client api coming in SE8/EE7 as well.
>
> On Fri, Nov 2, 2012 at 7:59 PM, Danny Coward <danny.coward_at_oracle.com
> <mailto:danny.coward_at_oracle.com>> wrote:
>
> Thanks Scott and Greg.
>
> So its looking like we will drop the extensions SPI for this version.
>
> What do others feel about the client API ?
>
> Thanks,
>
> - Danny
>
>
> On 11/1/12 3:15 PM, Greg Wilkins wrote:
>>
>>
>> On 25 October 2012 12:16, Danny Coward <danny.coward_at_oracle.com
>> <mailto:danny.coward_at_oracle.com>> wrote:
>>
>> The support for extensions in the Early Draft includes
>> support for web socket extensions in two ways:-
>>
>> 1) The ability to list installed extensions by name, and
>> provide an extension matching algorithm in the opening
>> handshake. (see e.g. ServerEndpointConfiguration)
>> 2) The ability to create a (portable) web socket extension
>> written in Java, and to install it in any JSR 356
>> implementation. (see, e.g. Extension, FrameBuilder)
>>
>>
>>
>> I see that most extensions are going to be between browser
>> implementations and server implementations. I see very little
>> need for application provided protocol extensions ( which is
>> almost an oxymoron!)
>> So deferring 2 is good - maybe even indefinitely.
>>
>> cheers
>>
>>
>>
>>
>> --
>> Greg Wilkins <gregw_at_intalio.com <mailto:gregw_at_intalio.com>>
>> http://www.webtide.com
>> Developer advice and support from the Jetty & CometD experts.
>
>
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>
>
>
>
> --
> You can find me on the net at:
> http://antwerkz.com <http://antwerkz.com/> http://antwerkz.com/+
> http://antwerkz.com/twitter http://antwerkz.com/github
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation