Salut,
John ROM wrote:
> Hi Jeanfrancois,
>> Datum: Tue, 14 Oct 2008 10:49:49 -0400
>> Von: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
>> An: dev_at_grizzly.dev.java.net
>> Betreff: Re: Grizzly 2.0 Feedback
>
>> Salut,
>>
>> John ROM wrote:
>>> Hi Alexey,
>>> as always I have just to much work at work but this weekend
>>> I did spend an 2 hours working with
>>> Grizzly 2.0.
>>>
>>> Just 2 comments or questions.
>>>
>>> 1)
>>> Maybe keep the MemoryManager Interface really slim?
>>> maybe witout the util wrap methods in there. For example when
>> integrating Ken's Slab Allocation Pool
>>> I am only interrested in allocate( int size ) and maybe int
>> maxAllocationSize();
>>> I don't want to have to be forced to implement wrap(..)
>> I'm also tempted to agree with you :-) Alexey is on vacation for another
>> week, so let's wait for him :-)
>>
>>
>>> 2) Grizzly 2.0 has 3 Abstractions :
>>>
>>> org.glassfish.grizzly.Transformer,
>>> org.glassfish.grizzly.filterchain.CodecFilter,
>>> org.glassfish.grizzly.filterchain.Filter
>>>
>>> Please correct me if I am wrong,
>>> so there are two API's which handle read /writes.
>>> A Filter API which is like Grizzly ProtocolChainFilter API
>> (selectorThread,XXXexecute Methods,WorkerThreads) and a (let me call it) TransFormer
>> API (Connection.read/write)
>>> My feeling is that CodecFilter should not extend Filter so
>>> that there would be no need to implement Filter. This would also make it
>> clearer that
>>> the processing is very different.
>>> Or have I missed something? Maybe CodecFilter needs some specific
>> FilterChain functionallity
>>> (other then List) ?
>>>
>> But we will need an interface for Codex-like filter, right? What this
>> interface should looks like?
>
> Actually just
>
> public Transformer getDecoder()
> public Transformer getEncoder()
>
> If you look at org.glassfish.grizzly.FilterChainTest you see both API's being used at the same time.
>
> But I think if you only use the methods
>
> WriteResult result = (WriteResult) filterChain.write(connection,message).get();
> ReadResult readResult =(ReadResult) filterChain.read(connection).get();
>
> a class like UTFStringFilter is bigger then it would need to be
>
> UTFStringFilter execute or postExecute
> will never be called (Maybe in async mode they will and I am overlooking a usage)
> The call graph is aso different opposed to setting up a server.
>
> So I would just like to check if any simplyfications could be possible?
You got me :-) I agree with you. I will start injecting bugs in Alexey's
code as soon as I can jump of GlassFish v3 (grrr).
A+
-- Jeanfrancois
>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>> Many Greetings
>>> John
>>>
>>>
>>>
>