Jeanfrancois Arcand wrote:
> Salut,
>
> the first disagreement we had today was about the needs, in 2.0, to
> have one ProtocolChain per Transport, instead of one ProtocolChain
> shared amongst Transport. Alexey thinks it complexity the programming
> experience when a simple Filter handle two or more transport (like the
> ReadFilter, which support UDP and TCP). So in Grizzly 2.0, the
> programming model would consist of:
>
> UDPTransport -> ProtocolChain_1 -> UDPReadFilter --> MyProtocolFilter
> TCPTransport -> ProtocolChain_2 -> TCPReadFilter --> MyProtocolFilter
>
> where in Grizzly 1.8, we had:
>
> UDPTransport -> ProtocolChain_1 -> ReadFilter --> MyProtocolFilter
> TCPTransport -> ProtocolChain_1 -> ReadFilter --> MyProtocolFilter
>
> I've objected about the proposal as I think the second approach is
> much more easy to handle. Ken (correct me if I'm wrong, which is quite
> possible) seemed to like the 1.8 approach as well. We stopped the
> discussion and now this is time to speak :-)
>
> I'm still -1 on the new approach, but let's start the discussion :-)
>
I'd like to see the rough application code needed for each approach.
I'm not really
convinced either way yet as to which is the best approach.
At some point, we presumably do something like (2.0):
UDPTransport udp = transportManager.makeUDPTransport( ... ) ;
TCPTransport tcp = transportManager.makeTCPTransport( ... ) ;
At this point, does each transport already have a default protocol chain?
Do I just need to call something like:
udp.getFilterChain().addFilter( myProtocolFilter ) ;
tcp.getFilterChain().addFilter( myProtocolFilter ) ;
In this case, it doesn't matter whether I have one or two ProtocolChains.
Is the filter chain shared across all connections in the transport?
If the filter chain has stateful elements (as in the CORBA case), we
need to create a new filter chain for each new connection managed by
the transport. How does that work?
Do we need something like a FilterFactory?
Thanks,
Ken.