On Nov 28, 2009, at 2:32 AM, Ashish wrote:
Well, choosing a suitable Data Structure to support all this will
again be interesting. Current implementation uses something
similar to
LinkedHashtable. Have to see if something simpler can be implemented
or out of the box API :-)
It's my opinion that new filters get created to simulate state
machine
changes and any other use is an ad hoc mechanism that can be more
cleanly
refactored into a state machine mechanism. With that said aa
session w/ N
fixed chains where each chain represents a state would fit the
bill. The
number of states is fixed. The composition of the state machine
can be
changed until the acceptor/connector have established the connection.
Acceptor -> ChainMachine -> IoHandler
inside the chain machine:
S1: IOF1 -> IOF2 -> IOF3 -> IOF5 -> IOF4
S2: IOF1 -> IOF3 -> IOF5 -> IOF4
S3: IOF1 -> IOF2 -> IOF3 -> IOF4
From a user's perspective things are quite easy to grok and most
cases the
chain machine degenerates into a single state chain.
Agree on point that we have to keep additional noise away :-)
What about the assertion that new filters only get created to simulate
a state machine?
So what's the best way proceed forward, now that we had a quite a good
discussion :-)
CODE IT UP! :)
Actually, when ever I make an API, I usually drive the API design by
actual coding examples. Take for example how I drove the design of
the HTTP client by implementing the Amazon S3/EC2 clients. My mantra
is that if the client use case doesn't use it then it doesn't go into
the API. Also, I design against interfaces so that implementation
details don't clutter my API thinking.
I can do to mock implementations for async HTTP and for an ASN1 codec.
Regards,
Alan
