Alexei Dets wrote:
> Hi!
>
> Jeanfrancois Arcand wrote:
>
>>> For me the biggest annoyances of the current Grizzly API are completely
>>> different ways of handling client vs server events and HTTP protocol
>>> implementation that doesn't work together with
>>> ParserProtocolFilter/ProtocolParser (I'd really like to be wrong on
>>> this).
>> Can you elaborate? Do you means you would have liked to be able to add
>> an HttpProtocolFilter instead of using the current
>> GrizzlyWebServer/SelectorThread API? Then once this filter got added you
>> would have liked to add your own ProtocolFilter than could process the
>> decoded HTTP?
>
> YES. But that's not all.
>
> Basically the framework gives the impression that it consists of two very
> different parts, that it was a code that was originally designed for HTTP
> server side _only_ and later was converted into a generic NIO framework
> that still has original HTTP protocol handling code that was never
> retrofitted to the new structure.
yes, this is exactly what happened. Technically it would have been bad
to break all the application written agains Grizzly 1.0. So we started
at 1.5.x with a new NIO framework supported the old http one.
>
> 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?
It's logical to assume
> that HTTP support should be built on this foundation and one should be
> easily able to implement such features as port unification for different
> protocols (one of them being HTTP) or HTTP requests pre-/post-processing
> (they should come as a messages out of ProtocolParser, shouldn't they? ;-)
> or HTTP requests interception etc. at this low level, _before_ HTTP will
> come to higher level Comet/Servlet logic.
Agree. But like I've said, we didn't want to loose the community build
around 1.0
>
> Unfortunately, the way things are now, HTTP is a completely different
> beast. :-( First of all, forget everything you know about Controller - for
> HTTP support this not the main entry point to the framework anymore, now it
> is SelectorThread. Second, forget about using
> ProtocolChain/ProtocolParser - HTTP uses StreamAlgorithm/ProcessorTask
> (deprecated!) & requires its own kind of worker threads, it is very
> difficult to integrate something additional at this level. Still it _is_
> possible to implement port unification/custom processing etc. with HTTP but
> this unfortunately involves completely different APIs with ProtocolFinder,
> ProtocolHandler, PUProtocolRequest etc. (that BTW are more difficult to use
> compared to the ProtocolParser API).
Noted. Any recommendations to improve?
>
> In other words in the Grizzly 1.9.x it is necessary to know two different
> sets of APIs that use completely different approaches to solving the same
> problems, it is not possible to treat HTTP generically as one of the
> protocols among others - it is THE PROTOCOL. And this is unfortunate :-(
Agree. This is something we must fix for 2.0 release
>
>>> But there is a minor thing that can be changed easily: IMHO
>>> TCPSelectorHandler.connect method should be public. The reason being the
>>> 100% asynchronous application that implements both client and server
>>> doesn't really need ConnectorHandlers: SelectorHandler
>>> (TCPSelectorHandler) already has the required functionality,
>>> ConnectorHandlers just complicate the things (i.e. they need to be
>>> released).
>> Interesting. In that case you will just use a CallbackHandler to
>> manipulate the transaction.
>
> Yes. It'll just handle connect and delegate event processing to
> ProtocolChain (to not reinvent the wheel). Actually very simple to
> implement (and I believe I got this idea from your blog ;-).
>
>> I think we can allow that but some of
>> features the current ConnectorHandler offer will not be included (like
>> configuring the socketChannel properly), and the final steps for
>> completing the connect operation. We just need to properly document the
>> method I guess. Can you file an RFE here:
>>
>> * https://grizzly.dev.java.net/issues/
>
> Done: https://grizzly.dev.java.net/issues/show_bug.cgi?id=735
>
> Regards,
Thanks!
-- Jeanfrancois
> Alexei
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>