directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <>
Subject Re: [asn1] Stateful Decoder question.
Date Wed, 05 Jan 2005 19:48:44 GMT wrote:
> Rich,
> I looks like you have really started digging into the Stateful codec stuff in asn.1.
 What do you think about it regarding your use cases?  What ways do you think it can be improved
or would another model work better?  Just looking for more feedback.

Heh.  Don't give me too much credit.  I've only looked on the surface at 
the StatefulDecoder interface and how it's used in Eve.  The only 
limitation I've run into is that there is no way to share state between 
the decoder and the request handler.  This is something that I've 
mentioned before, so I won't go into too great a detail.  Basically, 
depending on the state of the connection the decoder might be expecting 
the client to send certain things (commands vs. data for instance) and 
do different things with what it gets (parses it or just passes it 
along).  The problem arises that if there is an error in the request 
handler and the state should be changed, there is no way to notify the 
decoder of this change in state because there is currently no way of 
getting at the session in which the decoder is being used.  The protocol 
api doesn't have this limitation because the ProtocolProvider gets the 
client socket when the getDecoder() method is called so you can easily 
associate sessions with decoders and vice-versa.

> I'm asking because I myself and with others often criticize the callback approach.  Sometimes
it gets confusing and is not that easy for people to understand.  

It does seem confusing at first, I guess, but I kinda like it.  It's a 
simple way of communicating to the caller that something has happened 
and it needs to do something.  Another way to do it would be to have the 
caller and the callee share a queue and when the callee needs to send a 
message to the caller it enqueues it.  Then, the caller can either 
listen for updates to the queue via the publisher/subscriber pattern or 
it can poll the queue periodically.  I don't know which solution is 
better, I think they both have their own merits and drawbacks just like 
anything else does.


View raw message