BayeuxRouter Injection Need for Bayeux4Netty

[Trustin Lee (이희승)]

On Sun, Sep 27, 2009 at 4:27 PM, Dai Jun <guiwuu at gmail.com> wrote:
> Hi Trustin and Bob,
>
> Sorry for my late response. I got a cold and was away from computer
> for some days. But don't worry, it's not H1N1 and I already recover
> from it:).

Phew! :)

> I like both of your ideas.
>
>> On Sep 20, 2009, at 10:23 PM, Trustin Lee (이희승) wrote:
>>
>> To support the two cases above (extension or re-implementaiton), I
>> think BayeuxRouter should be an interface and the current
>> implementation should be renamed to something like
>> 'DefaultBayeuxRouter'.
>>
>> And then, we need to allow a user to specify a BayeuxRouter
>> implementation in the constructor.  The constructor argument could be
>> optional so that the default router implementation is used if no
>> router is specified.
>
> +1. I'd like this idea. But I am not very clear how to do this
> perfect. Because BayeuxConnection also depends on BayeuxRouter
> besides BayeuxEncoder/Decoder. Of course, we also can specify it in
> constructor of BayeuxConnection like in BayeuxDecoder/Encoder. But the
> codes seem to be some redundant. Is there more beautiful way? Like IoC
> container. Just a think, I am not familiar with it and looking forward
> to your suggestions.

I think it might become simpler if BayeuxRouter creates a
BayeuxConnection rather than letting user create one by himself.  As
far as I know, the only place where a new BayeuxConnection is created
is BayeuxDecoder, and it's tightly coupled with BayeuxRouter.

I'm not sure making BayeuxRouter even act as a factory of
BayeuxDecoder and BayeuxEncoder, but it might be fine as
BayeuxDecoder/Encoder is tightly couple with BayeuxRouter at this
moment.

To depict this idea:

    BayeuxRouter router = new DefaultBayeuxRouter();
    ...
    pipeline.addLast("...", router.newEncoder());
    pipeline.addLast("...", router.newDecoder());
    ...

> On Mon, Sep 21, 2009 at 9:38 PM, Bob McWhirter <bmcwhirt at redhat.com> wrote:
>> Trustin, I think that'd be a perfect solution.
>>
>> Taking it a step further, I think I'd enjoy creating, even if only in
>> my own codebase, an abstract handler that's more like HTTP Servlets.
>> Instead of a general handling method, branch out into a doSubscribe(),
>> doUnsubscribe(), doConnect() etc type of methods.  Then the default
>> handler could have a default implementation for doSubscribe() which
>> could be overriden by subclasses if they wanted to do more.
>
> Cool idea, it helps a lot. I'd like to add it ASAP.
> AbstractBayeuxHandler should be a suggestion way to develop Bayeux
> APPs. Users also are able to directly use BayeuxEncoder/Decoder in
> Netty's upstream/downstream chain. Do you agree?

Yes, good idea. :)

Cheers

— Trustin Lee, http://gleamynode.net/