That's the power of NIO: no blocking waits! ;)
Bo Li wrote:
> Wow... That's some fast turnaround.. I will take a look tomorrow.
>
> Thanks again!
> Bo
>
>
> On 5/20/09 7:25 PM, "Oleksiy Stashok" <Oleksiy.Stashok_at_Sun.COM> wrote:
>
>
>> Bo,
>>
>> BTW, filterChain.getCodec() should work now.
>> So, all Filters in a FilterChain, which implement CodecFilter will take part
>> in message transformation.
>>
>> WBR,
>> Alexey.
>>
>> On May 19, 2009, at 15:56 , Bo Li wrote:
>>
>>
>>> Ahh... Now it all makes sense. I saw all the codec related code in the repo
>>> but donšt see how they can be used. This should work for the client side and
>>> I like the message abstraction since we do that now anyways. I guess the
>>> encode transform calls the filters from last to first and the decode from
>>> first to last? What will the decode side look like? Is the codec API designed
>>> as a replacement to the filter / handleRead/Write methods of implementing
>>> custom protocols? How do you think it will affect performance and memory use?
>>>
>>> Grizzly 2.0 is getting very interesting and I canšt wait to see the next set
>>> of changes!
>>>
>>> Thanks again
>>> Bo
>>>
>>>
>>> On 5/19/09 3:01 PM, "Oleksiy Stashok" <Oleksiy.Stashok_at_Sun.COM> wrote:
>>>
>>>
>>>
>>>> Hi Bo,
>>>>
>>>> looks like you're looking for Codec API to be supported by FilterChain
>>>> (FilterChain.getCodec()).
>>>> We have that API, but it's not implemented for FilterChain. I'll complete
>>>> the implementation nearest time.
>>>>
>>>> It will work like:
>>>>
>>>> Buffer buffer = filterChain.getCodec().getEncoder().transform(message);
>>>> connection.getStreamWriter().writeBuffer(buffer);
>>>>
>>>> This way, tranform will sequentially call each Filter, which implement
>>>> FilterCodec interface, to encode the message.
>>>>
>>>> Does this sound good for you?
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>>
>>>>
>>>>> I have a question about the design of client side code, or any non IO
>>>>> event
>>>>> driven code, using Grizzly 2.0. I understand that processing is triggered
>>>>> on
>>>>> IO events and each filter in the filter chain will handle the event
>>>>> accordingly. This works well in a server-side request-response protocol
>>>>> model. The protocol parser can just read and write to the StreamReader and
>>>>> StreamWriters from the FilterChainContext without having knowledge of
>>>>> previous filters on the chain.
>>>>>
>>>>> However, what I don't see is how to do the same on the client side or if
>>>>> the
>>>>> server needs to send unsolicited messages to the client. In these cases,
>>>>> there are no IO events to trigger the filter chain but the protocol
>>>>> message
>>>>> still needs to be handled by the filters before going out the wire. I
>>>>> understand for SSLFilter I can just wrap the SSLStreamWriter around
>>>>> StreamWriter from the TCPConnection but then my protocol parser code will
>>>>> need to know about the previous filters on the chain and their
>>>>> implementation. If I change the filters in the chain I will also need to
>>>>> change the wrappings of StreamWriters and StreamReaders.
>>>>>
>>>>> Is there a easier way to do this? I envision a two-way filter chain where
>>>>> I
>>>>> just write to "protocol" side of the chain and previous filters will
>>>>> process
>>>>> the write request before sending it out the wire.
>>>>>
>>>>> Thanks again
>>>>> Bo
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>