directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <trus...@gmail.com>
Subject Re: Proposing some changes to the ProtocolProvider API
Date Fri, 10 Dec 2004 00:57:15 GMT
I agree with you about Encode/Decode issue.  IMHO, encodeOccurred and
decodeOccurred callback is ugly, so I suggested another interface
'ProtocolCodec':

http://svn.apache.org/viewcvs.cgi/incubator/directory/seda/branches/trustin/src/java/org/apache/mina/protocol/ProtocolCodec.java?rev=111268&view=auto

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:

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);

}

The weakness of this interface is its return type is very ambiguous,
so I've done in MINA like this:

...
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.

Cheers,
Trustin Lee

On Thu, 09 Dec 2004 17:59:05 -0500, Berin Loritsch
<bloritsch@d-haven.org> wrote:
> Currently the protocol provider API is a bit difficult to ensure things
> are happening
> properly, and to abstract out properly.  It currently assumes that the
> current SEDA
> API will be the implementation.
> 
> I would like to alter it in a way that would work for both MINA and my SEDA
> refactoring--so please Trustin, let me know if this works for you...
> 
> In order to have Encode, Response handling, and Decode operations working
> without knowlege of the network system, we have to standardize on what it
> can expect.  I would like to make it something along these lines:
> 
> interface ProtocolProvider
> {
>    Object[] NO_RESPONSE = new Object[0];
> 
>    Object decode(Socket client, ByteBuffer buffer);
>    // returns NO_RESPONSE if there is nothing further to do
>    Object[] processRequest( Object request );
>    ByteBuffer encode( Object response );
> }
> 
> This will allow the smallest footprint for really small and easy
> systems, yet allows
> more complex protocol providers to delegate to helper objects as need
> be.  I have
> no problems with using the current factory approach either--as long as
> the encode/
> decode process returns something that can be passed on.
> 
> The way it would be used is something like this:
> 
> Object request = provider.decode(netEvent.socket(), netEvent.getBuffer());
> Object[] response = provider.processRequest( request );
> 
> for (int i = 0; i < response.length; i++)
> {
>    netEvent.setBuffer( provider.encode( response[i] );
> }
> 
> //...
> 
> It would work equally well in both seda and mina environments--at least IMO.
> 
> Currently the encoder explicitly publishes the "encode event" directly
> to the
> event publisher from within client code.  In this sense it is explicitly
> tied to the
> current SEDA implementation.
> 
> How does this sound?
> 
> --
> 
> "Programming today is a race between software engineers striving to build bigger and
better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning."
>                - Rich Cook
> 
> 


-- 
what we call human nature is actually human habit
--
http://gleamynode.net/

Mime
View raw message