BayeuxRouter Injection Need for Bayeux4Netty

[Trustin Lee (이희승)]

Bob,

I love the idea.  It sounds just right to me.  WDYT Danny?

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

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.
>
> Also, I'm not sure if I like the stack itself handling responses if
> you turn them around from your app's handler.  At this point, if you
> receive a Subscribe request, and just turn that exact object back as a
> response, the response chain will see it and create an appropriate
> Subscribe response.
>
> To me, it'd seem sensible to put that behaviour into an
> AbstractBayeuxHandler which I could subclass.  That way, everything is
> still handled at the end of the chain, if my subclass chose to invoke
> the super-classes's handling of certain messages.  That could also
> simplify the actual bayeux protocol stack itself.
>
> 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.
>
>        -Bob
>
>
> On Sep 20, 2009, at 10:23 PM, Trustin Lee (이희승) wrote:
>
>> I think the current BayeuxRouter implementation fits pretty well for
>> most use cases.  What Bob says is that a user might want something
>> more (or something diffferent) that the default behavior.  In such a
>> case, the user might be able to implement such an additional feature
>> by extending the current BayeuxRouter implementation or reimplementing
>> the router.
>>
>> 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.
>>
>> -- Trustin Lee, http://gleamynode.net/
>>
>> On Wed, Sep 2, 2009 at 5:05 PM, Dai Jun <guiwuu at gmail.com> wrote:
>>> Hi all,
>>>
>>> I am sorry to intercept you by this. I copy Bob, Trustin and I's chat
>>> of  BayeuxRouter injection here to have further discussion. And I am
>>> looking forward to your suggesions. Thanks.
>>>
>>> On Wed, 2 Sep 2009 07:09:11 +0900 (KST) Bob McWhirter
>>> <bmcwhirt at redhat.com> wrote:
>>>>> I'd also like to not rely on the singleton
>>>>> BayeuxRouter.getInstance(), but other code seems to assume that's
>>>>> how
>>>>> we get it.  I'd like to be able to inject a router to be used by
>>>>> BayeuxDecoder and BayeuxConnection.
>>>>>
>>>>> We could instead inject a BayeuxRouter instance into BayeuxDecoder,
>>>>> which passes it along to BayeuxConnection.  All avoiding
>>>>> getInstance()'s singleton, and allowing for multi-application
>>>>> isolation.
>>>>
>>>
>>> On Wed, Sep 2, 2009 at 8:02 AM, 이희승<trustin at gmail.com> wrote:
>>>> +1
>>>
>>> +1, too. I was thinking about this problem recently. The current
>>> singleton model is not enough in real server cases. With injection,
>>> we
>>> can manage router in AS. But I am not familiar with injection. I have
>>> to postpone it to next next update. If you or anybody else know about
>>> it, we can speed it up. I'd love to discuss with it in another new
>>> thread.
>>>
>>> Best regards,
>>>
>>> Dai Jun or Danny Dai(in English) - http://guiwuu.googlepages.com
>>> GTalk: guiwuu at gmail.com | QQ: 93409048 | MSN: guiwuu at hotmail.com |
>>> Twitter: @guiwuu
>>> Sent from Beijing, 11, China
>>> Charles de Gaulle  - "The better I get to know men, the more I find
>>> myself loving dogs." -
>>> http://www.brainyquote.com/quotes/authors/c/charles_de_gaulle.html
>>>
>>> _______________________________________________
>>> netty-dev mailing list
>>> netty-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/netty-dev
>>>
>>
>> _______________________________________________
>> netty-dev mailing list
>> netty-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-dev
>
>
> _______________________________________________
> netty-dev mailing list
> netty-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-dev
>