hello!
I do not have a strong oppinion about this but it seems to me that the first
approach is simpler (keep it simple), easier to understand, more modular and
may be easier to extend.
Jeanfrancois Arcand-2 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 :-)
>
> A+
>
> --Jeanfrancois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>
>
--
View this message in context: http://www.nabble.com/-Grizzly2.0---Issue-1--ProtocolChain-per-Transport-tp17989506p17990451.html
Sent from the Grizzly - Development mailing list archive at Nabble.com.