directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <rwall...@thewallacepack.net>
Subject Re: Proposing some changes to the ProtocolProvider API
Date Fri, 10 Dec 2004 15:46:39 GMT
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.  Even tho the 
callbacks may seem ugly, they are really useful.  In the cases that I've 
been talking about where a ProtocolProvider implementor may want to 
create sub-pipelines to handle decoding/request processing/encoding it 
is essential that encode() and decode() calls return fast so the calling 
thread isn't tied up waiting for the sub-pipeline to get done.

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

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

Rich

Mime
View raw message