Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of aok123@bellsouth.net
 designates 205.152.59.66 as permitted sender)
Message-ID: <41C2FA60.4040601@bellsouth.net>
Date: Fri, 17 Dec 2004 10:25:20 -0500
From: Alex Karasulu <aok123@bellsouth.net>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Apache Directory Developers List <directory-dev@incubator.apache.org>
Subject: Re: [mina] ProtocolHandler interface
References: <768dcb2e04121700222569871d@mail.gmail.com>
 <41C2D722.6080009@d-haven.org>
In-Reply-To: <41C2D722.6080009@d-haven.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Berin Loritsch wrote:

> Trustin Lee wrote:
>
>> Hi.
>>
>> I admit I am very accustomed with Netty-like session handler
>> interface, but the entry users like Alex and other persons would not
>> feel so familiar with it:
>>
>> http://svn.apache.org/viewcvs.cgi/incubator/directory/network/trunk/mina/src/java/org/apache/mina/protocol/ProtocolHandler.java?rev=122627&view=auto 
>>
>>
>> So I want to know what all of you guys are thinking about this
>> ProtocolHandler interface, and to improve its usability.
>>
>> If most of protocols are OK with simple request-response-close
>> connection model, it would be also possible to provide two difference
>> interfaces, ProtocolHandler (simple one) and AdvancedProtocolHandler
>> which extends ProtocolHandler and provides full event handler methods
>> like the current revision of ProtocolHandler.
>>
>> If is absolutely OK if you can suggest me totally different and better
>> interface of course.
>>
>> Cheers,
>> Trustin
>>  
>>
> Trustin, did you look at the protocol-api stuff I committed?
>
> I'm not married to it, but my goal was to not stray too far from what 
> we currently
> have, simplify, yet keep the power we need.  As far as I am concerned, 
> it works
> for me.  The question of course is will it work for you and Mina?

+1

>
> I'd like to have one protocol api that we both use, and work from that 
> perspective.
> As much as possible I would really like the protocol providers to not 
> have to know
> anything about the networking layer and vice versa.  

This is the goal.  If the same provider could work in mina, seda, sedang 
then the newtork layer is interchangable.  Plus keep the focus on what 
your clients need.  Right now you have two of your biggest clients: LDAP 
and Kerberos.  Also Richard Wallace made some excellent points about his 
requirements for an email server.  It is feasible that what works for 
Richard's server may work be needed for James to use one of these 
networking layers.  He made a good point about needing to send a message 
to a client upon connection - excellent example of a use case we did not 
think of. 

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=directory-dev@incubator.apache.org&msgNo=3006

We need to be asking ourselves do these frameworks and the protocol API 
have the flexibility to support these use cases without hacks?  And 
while doing so do they impose the smallest learning curve possible.  
Making a sweet networking layer that's efficient and slick is great but 
its not going to win users alone.  You don't need me to tell you how 
important a user community around the code is.

>
>
> As to open-response-close, that is more for stateless protocols like 
> HTTP.  

Or UDP protocols which again as you say is stateless.

> From what I understand it is very common for LDAP clients to remain 
> connected for extended
> periods of time and perform many request/response cycles.  Not to 
> mention the HTTP
> keep-alive option of doing many request/responses from one connection 
> as well (usually
> for all elements in the same page).
>