directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Proposing some changes to the ProtocolProvider API
Date Fri, 10 Dec 2004 17:18:11 GMT
Richard Wallace wrote:

> Berin Loritsch wrote:
>
> <snip/>
>
>> Currently, the ProtocolProvider has three methods: 
>> getDecoderFactory(), getEncoderFactory(), and getRequestHandler()
>>
>> That is fairly workable; however, there are two levels of 
>> abstraction--the ProtocolProvider is a factory for the request 
>> handler, but only returns the factory for the encoders and decoders.  
>> Can we simply make the ProtocolProvider a Factory?  That would 
>> simplify it in this way:
>>
>> // Responsibility of ProtocolProvider to write
>> interface ProtocolProvider
>> {
>>    StatefulDecoder getDecoder( Socket client, DecoderCallBack 
>> callback );
>>
>>    RequestHandler getRequestHandler( Socket client, RequestCallBack 
>> callback );
>>
>>    StatefulEncoder getEncoder( Socket client, EncoderCallBack 
>> callback );
>> }
>>
>> // Responsibility of ProtocolProvider to write
>> interface StatefulDecoder
>> {
>>    // internally calls the DecoderCallBack when something is there to 
>> send on
>>    void decode(ByteBuffer buffer);
>> }
>>
>> // Responsibility of ProtocolProvider to write
>> interface RequestHandler
>> {
>>    // internally calls the RequestCallBack when any response is ready
>>    void handleRequest(Object fromDecoder);
>> }
>>
>> // Responsibility of ProtocolProvider to write
>> interface StatefulEncoder
>> {
>>    // internally calls the EncoderCallBack when buffers are ready.
>>    void encode(Object fromRequestHandler);
>> }
>>
>> // Responsibility of network system to write
>> interface DecoderCallBack
>> {
>>    void decoded(Socket client, Object requestObject);
>> }
>>
>> // Responsibility of network system to write
>> interface RequestCallBack
>> {
>>    void response(Socket client, Object responseObject);
>> }
>>
>> // Responsibility of network system to write
>> interface EncoderCallBack
>> {
>>    void encoded(Socket client, ByteBuffer buffer);
>> }
>>
>> This takes things like the "XXXManager" out of the picture--the 
>> responsibilties are much smaller.
>> It also makes it easier to forward events asynchronously when they 
>> happen.  As far as the network
>> is concerned, only the Socket identifies a client--session objects 
>> and other more complex things are
>> part of whatever protocol is being serviced by the network layer.
>>
>> And more importantly, this allows us to identify a specific 
>> ProtocolProvider API.  This API can
>> (and should) be a dependency of the network layers and the individual 
>> providers.  However the
>> protocol providers should not have to have a dependency on the 
>> network layer.
>>
>> Currently we have part of the provider API provided by snickers, and 
>> yet another part of it provided
>> by the network API.  It makes the project hierarchy more difficult to 
>> manage as well.  By separating
>> out the protocol provider API into its own _clearly_marked_ 
>> subproject, we can clean up the
>> dependency structure in a way that truly decouples the network layer 
>> from the protocol layer--which
>> also gives us more of an opportunity to switch things up and optimize 
>> things without fearing breaking
>> the different protocol providers.
>>
>> It also makes it tremendously easier to add new protocol providers as 
>> necessary.
>>
>
> I like this much better than the first suggestion.  

Me too.

> After doing some more looking at the current ProtocolProvider last 
> night and starting to try and grok it so I could begin creating an 
> SMTPProtocolProvider I found myself asking the same question Berin 
> has, "Can't this be/Shouldn't this be much simpler?"

Ok well the more users saying this same thing certainly makes me think 
we may have to simplify more.

>
> I think this second approach Berin has suggested achieves that but 
> keeps the flexibility of the way it's implemented now.

Cool.

Mime
View raw message