directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Proposing some changes to the ProtocolProvider API
Date Fri, 10 Dec 2004 06:15:41 GMT
Trustin Lee wrote:

>I agree with you about Encode/Decode issue.  IMHO, encodeOccurred and
>decodeOccurred callback is ugly, so I suggested another interface
It's a classic callback and was designed to be ugly :-). I have not 
found other stackable approaches that are better yet.

I don't agree that this is better or at least don't think so at first 
glance but I can be convinced otherwise.  Yeah the callback is ugly I 
admit that.  This is not all that much better IMO.  Until I find 
something that really moves me I'm not going to rush to change things 
because of opinions.  I need more than opinions and that goes for my 
own.  I'm patient until the lightbulb really turns on.

Also these changes are not going to happen for a while.  If you're 
shooting for any integration before a release we're going to run into 
problems.  The more I read these trails the more I'd like to see these 
things come to fruition with everything considered but I'm afraid this 
will not happen the right way until after the 0.8.0 release. 

With these big changes to the design we're going to have to work on a 
developmental release right after 0.8.0 on the trunk which can be 0.9.0. 

>Similar to yours, right? :)
>But I'm negative on merging codec and RequestHandler into
>ProtocolProvider.  So I propose modifying RequestHandler and Snickers
>(stateful codec).  Here is new RequestHandler:
So you are merging the NoReplyHandler, SingleReplyHandler, and 
ManyReplyHandlers into a single Handler interface?

>inteface RequestHandler {
> * Processes the specified request and returns the response event.
> *
> * @param request A single request event object
> * @return A single response event object, Collection of response
>event objects, or null if no response is required.
> */
>Object handle(Object request);
Yep looks like that's what you're doing.

>The weakness of this interface is its return type is very ambiguous,
>so I've done in MINA like this:
Yeah I agree that's why I had the 3 different handler types.

>void messageReceived(ProtocolSession session, Object message) {
>    ... do some logic ...
>    session.write(response);
>    session.write(response);
>    ...
>If you don't need to fire any responses, then you can just return this
>handler method without calling session.write().  If you have to fire
>multiple responses, you can call it more than once, too.  I think
>calling back like this can be more intuitive and reduces overhead to
>create response collections/arrays than returning is.
There is some appeal to this I do admit it.  I really want to explore 
this.  Again I feel it needs to be more intuitive to users.  Trustin I 
think you should not rush with this really to make it in time for a 
0.8.0 release.  These ideas are great and I'd like to digest and see 
them mature rather than rushing.  Plus I think Berin needs some time on 
his end too.

Regardless of what happens I'm starting to believe that we're going to 
need to use a combined approach.  Perhaps build a server that can switch 
from one mechanism to another based on load.  In any case the 
ProtocolProvider interface is pivotal for interoperability.  I'm glad we 
are all communicating our ideas on this stuff.


View raw message