Hi!
> > I.e., if we are working with the Grizzly in general then we have to deal
> > with Controller, SelectorHandler, ProtocolChain, ProtocolFilter,
> > ProtocolParser etc. - it is a rather straightforward and logical API
> > (client side support with ConnectorHandler & CallbackHandler is the
notable
> > exception, it doesn't quite fit in this picture).
>
> I'm not 100% in agreement :-) How would you have supported client side?
The problem is not in CallbackHandler or ProtocolChain APIs themselves as
two ways of doing the same thing, the problem is that both of them are
incomplete (or may be "asymmetric" describes this better) and conflict with
each other.
For example, if I'm programming the server part with SelectorHandler +
ProtocolChain I have no _simple_ way to process incoming connections, there
is no analogue to CallbackHandler.onConnect at all. There is
SelectorHandler.onAcceptInterest but this not even nearly the same because
it is much more complex to implement (involves manipulations with
Grizzly/connection internals) and because it is called for _server_socket_,
not with the SelectionKey of the already accepted and established
connection. So, handling of new connections in this two APIs is completely
different even in many cases the application logic for both of these case
can be the same - this is confusing and inconsistent. I'd say that
SelectorHandler lacks onConnect method.
Another example, if you have a ProtocolChain defined and you have a
CallbackHandler then CallbackHandler's onRead method will not be called
(apart from a first couple of times) because some of the filters
(ParserProtocolFilter) have a "nice" habit of overwriting existing
selection key attachment (i.e. CallbackHandlerSelectionKeyAttachment). This
effectively means that you can delegate from CallbackHandler.onRead to
ProtocolChain but only completely, ProtocolChain will take over all event
handling. Means that onRead handler has somewhat limited use. And if
SelectorHandler has an AsyncQueueWriter defined then onWrite will never be
called.
In short we have completely different ways for onConnect processing logic
(for no good reason), conflict between CallbackHandler & ProtocolChain that
sometimes work together but not always and two barely usefull methods
(onRead/onWrite) in CallbackHandler. This is a mess, currently it is just
not possible to write any application beyond "Hello World!" without
in-depth study of Grizzly internals :-(
For complex apps I'd prefer to have onConnect in SelectorHandler together
with some way to indicate that all processing is asynchronous and should be
delegated to ProtocolChain and AsyncQueueWriter - this will eliminate the
need for CallbackHandler completely (ConnectorHandler is already useless).
For other apps (probably pure client apps) some API with Futures will be
probably more suitable and easy to use.
Regards,
Alexei