Let me clarify that the byte streams are data, not protocol message.
The ProtocolHandler need to aggregate the stream data to form a protocol
message as desired.
As I mentioned in the proposal:
"Note: the use of streams and notification methods in these interfaces
will need to be made consistent with any non-blocking I/O support added
to the Servlet API. Consider this a rough sketch to give you the general
idea of how this could work."
So, there will be adjustment to the proposed WebConnection and
ProtocolHandler.
Thanks for raising the question on half close.
I am not sure whether we want the protocol handler to change the linger
setting.
If we add half close related API to WebConnection as follows:
package javax.servlet.http;
public interface WebConnection {
public InputStream getInputStream();
public OutputStream getOutputStream();
public void shutdownInput();
public void shutdownOutput();
}
Is it good enough? Or we need some other configuration.
I have a concern on whether one should expose the Socket object as this
is too general.
Shing Wai Chan
On 10/16/11 3:30 PM, Greg Wilkins wrote:
>
>
> Shing Wai Chan,
>
> I do not like this approach for Upgrade for several reasons:
>
> * It does not allow containers to provide implementations of
> WebSockets (or other protocols)
>
> * Byte streams are not sufficient for full
> implementation/configuration of protocols. You need access to the
> socket API for controlling such this as half closes, linger setting
> and a wide range of other tuning parameters available on that API.
>
> * It does not support efficient NIO ByteBuffers
>
> * It duplicates work that might be done for an async servlet IO API.
>
>
>
> I think we need to consider upgrade support in several parts:
>
> 0) An upgrade request is initially processed like any other request -
> authenticated, authorised, filtered etc. A normal response may be
> served including redirections and errors.
>
> 1) To handle the upgrade, the application needs to find a provider for
> the protocol, which may be either provided either by the container or
> by the application. Container implementations should have priority
> over application implementations. Thus I believe we need an API where
> applications can register protocol providers and from which we can
> request a provider (either container or application provided).
>
> interface ProtocolConnection
> {
> }
>
> interface ProtocolProvider
> {
> ProtocolConnection init(ServletRequest,ServletResponse,Object
> applicationHandler)
> }
>
> servletContext.registerProtocolProvider(String protocolName,
> ProtocolProvider pp);
> servletContext.getProtocolProvider(String protocolName);
>
>
> 2) Once a protocol provider is available, the application will
> typically need to initialise the connection by created a protocol
> handler object (probably implementing some API of another JSR).
> Binding the application object to the connection can be done with the
> ProtocolProvider.init method. Within this init method, the
> provider might be container provided and us arbitrary mechanisms to
> setup the IO; or it may be application provided, in which case it can
> use the async IO api that we have discussed to access input/output
> byte streams.
>
> 3) Only once we have the accepted request, the protocol provider and
> the protocol handler do we actually accept the upgrade. This allows
> failures at any stage to be well handled. So in short the process
> would look like:
>
> ProtocolProvider provider =
> servletContext.getProtocolProvider(protocolName);
> ProtocolConnection connection =
> provider.init(request,response,myApplicationHandler);
> response.upgrade(connection);
>
>
>
> regards