Return-Path: Delivered-To: apmail-incubator-directory-dev-archive@www.apache.org Received: (qmail 65559 invoked from network); 10 Dec 2004 17:17:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 10 Dec 2004 17:17:57 -0000 Received: (qmail 34769 invoked by uid 500); 10 Dec 2004 17:17:56 -0000 Delivered-To: apmail-incubator-directory-dev-archive@incubator.apache.org Received: (qmail 34720 invoked by uid 500); 10 Dec 2004 17:17:55 -0000 Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list directory-dev@incubator.apache.org Received: (qmail 34701 invoked by uid 99); 10 Dec 2004 17:17:55 -0000 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=FROM_ENDS_IN_NUMS,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of aok123@bellsouth.net designates 205.152.59.69 as permitted sender) Received: from imf21aec.mail.bellsouth.net (HELO imf21aec.mail.bellsouth.net) (205.152.59.69) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 10 Dec 2004 09:17:54 -0800 Received: from [172.16.1.7] ([65.80.200.112]) by imf21aec.mail.bellsouth.net (InterMail vM.5.01.06.11 201-253-122-130-111-20040605) with ESMTP id <20041210171752.MAKA2054.imf21aec.mail.bellsouth.net@[172.16.1.7]> for ; Fri, 10 Dec 2004 12:17:52 -0500 Message-ID: <41B9DA53.3080206@bellsouth.net> Date: Fri, 10 Dec 2004 12:18:11 -0500 From: Alex Karasulu User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: Proposing some changes to the ProtocolProvider API References: <41B8D8B9.8060600@d-haven.org> <41B93A89.4040204@bellsouth.net> <41B9AEFC.206@d-haven.org> <41B9C4DF.8080702@thewallacepack.net> In-Reply-To: <41B9C4DF.8080702@thewallacepack.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Richard Wallace wrote: > Berin Loritsch wrote: > > > >> 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.