Re: [beep4j-user] Limiting the size of messages

[Simon <co...@gm...>]

On Jan 17, 2008, at 4:46 PM, Alan D. Cabrera wrote:

>
> On Jan 16, 2008, at 9:32 PM, Simon wrote:
>
>>
>> On Jan 15, 2008, at 8:31 AM, Alan D. Cabrera wrote:
>>
>>>
>>> On Jan 14, 2008, at 9:34 PM, Simon wrote:
>>>
>>>>
>>>> On Jan 14, 2008, at 9:55 PM, Sam Roberts wrote:
>>>>
>>>>> On Mon, Jan 14, 2008 at 11:46:31AM -0800, Simon wrote:
>>>>>>
>>>>>> How would you combine those two ways of message processing into
>>>>>> the
>>>>>> current code? What kind of API do you envision?
>>>>>
>>>>> Not sure. Maybe if the frame level handlers are registered, they
>>>>> get
>>>>> called. If not, the library internally accumulates frames into a
>>>>> message, and calls the message hander with the entire message, as
>>>>> it
>>>>> does now?
>>>>
>>>> Or maybe I could just pass frames through beep4j and accumulate the
>>>> messages before calling the ChannelHandler / ReplyHandler if
>>>> desired.
>>>> So the default would be to pass frames unless something is done
>>>> about
>>>> it.
>>>>
>>>
>>> What about making the FrameHandler a FrameHandler interceptor stack?
>>> The same for ChannelHandler/ReplyHandler.
>>
>> I don't want to allow FrameHandler to be implemented by application
>> programmers (at least not at the current place in code). It is just
>> to low level. The whole channel management profile and message
>> correlation is implemented on top of this functionality and would
>> have to be reimplemented by the application programmer.
>
> Not sure how using an interceptor stack means that the application
> programmers would be managing the message correlation, etc.  I was
> thinking that the programmer could add interceptors before and/or
> after yours.  Let's zero in on this disconnect between you and I.
>

As mentioned in an another e-Mail there are two somewhat orthogonal  
issues. One is doing something about too large incoming messages and  
the other is handling individual frames (instead of assembled  
messages). From your statements it seems you just want a way to solve  
the first issue (that was your original point). Do you envision any  
other way the FrameHandler interceptors might be useful? I mean, most  
of the BEEP specific stuff happens inside the Session (channel  
management, message correlation, state management, ...). The  
FrameHandlers are very raw, they can not even send a response.

If it is possible to provide a solution for the second issue mentioned  
above (by making the whole beep4j library message operate on frames)  
then your problem can easily be solved. If I find a serious reason why  
this is not a good idea, I'll rather implement the callback from  
FrameHandler to ChannelHandler directly in beep4j. I consider the  
FrameHandler interface (and its implementations) an internal  
implementation detail I'd rather not expose to users of beepj4.

>> A solution that sounds more promising is to reimplement beep4j so
>> that frames are passes through the library up to the
>> ChannelHandler / ReplyHandler. This would shift the responsibility
>> to assemble messages to the application. Possibly, the assembling
>> could be done by a ChannelFilter. I think the frame based mode is
>> feasible. The big question is how the API will look like. Once the
>> trunk stabilizes I'll try to come up with a proposal.
>
> If I understand you correctly this would make the ChannelHandlers and
> ReplyHandlers pretty bulky.  I would much rather have a collaboration
> between my CH/RH instances and the FH interceptors.  This will keep my
> handlers focused, easier to read and debug.

Why would that be? I don't think we'll understand each other without a  
concrete code / API. I'll think about it and post my ideas to the list  
when I'm confident that it's feasible.

Simon