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
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>