directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Proposing some changes to the ProtocolProvider API
Date Fri, 10 Dec 2004 05:56:25 GMT
Berin Loritsch 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 );
> }

Sorry but from a first look that's a negative.  All your response 
objects are expected to be created in advance.  Namely I'm referring to 
he Object[] returned from the processRequest() method.  Basically think 
about Search operations in Eve....

Search requests can return 1 or more responses that equals zero or more 
ExtendedResponses or SearchResultEntryResponses followed by as 
SearchResultDone to terminate the request.  Eve is designed to stream 
out search results rather than keep an entire result set in memory.  By 
having an Object[] return all responses at once I have to cache all the 
results before even starting to return any entries.  This will make Eve 
extremely inefficient.  Hence the reason why I return an Iterator.  
Every time you ask for the next response its pulling an entry from the 
database which matches the filter. 

Eve does not fetch an entry until you're ready to return it to a 
client.  This keeps the perclient resources used to a minimum. Without 
this performance would degrade considerably.  So look at using a Cursor 
friendly (one that can wrap a cursor) construct like Iterators, 
Enumerations, et, cetera.

>
> 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.
>
I like the factory approach because you can delay when the 
encoder/decoder pairs are created and by which module.  There is lots of 
flexibility here.   Otherwise you're basically making the provider the 
codec as well as the request processor.  These are three separate 
functions that need not be coupled.  Let's explore why the 
ProtocolProvider interface is so inhibitive.  What problems are you 
having with it?

> 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.
>
There is an EncoderManager which does the publishing since as a 
component it holds a dep on the event router.  No encoder will publish 
to an event queue.  Encoders simply trigger the manager to enqueue.

> How does this sound?
>
Sorry Berin I cannot go with this for the reasons stated inline.  
However I'm open to working with you.  I just need to know why you're 
having problems.  I also want to make sure you're familiar enough with 
the current SEDA and Eve code to understand why I made most of my design 
choices and why I cannot veer away from certain mechanisms. 

Alex






Mime
View raw message