directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Rodriguez <>
Subject Re: [seda] Session acces in the decoder
Date Fri, 17 Dec 2004 17:35:58 GMT
That was a great example.  I've seen this elsewhere.  Big +1 from me.


Richard Wallace wrote:
> Hey guys,
> Another limitation that I've found while working with the old seda 
> implementation is that occasionally the decoder does need access to the 
> clients session.  In the case I'm looking at the client sends commands 
> to the server, the decoder parses the command and passes along the 
> appropriate object to the next stage.  If the command is invalid in the 
> next stage (it's being used in the wrong context or wasn't preceded by 
> another command that is needed), the decoder needs to know about the 
> failure to move from one state to another.
> Let me try and give a more concrete example.  In the SMTP protocol a 
> transaction is started with a 'MAIL' command.  That should be followed 
> by one or more 'RCPT' commands to tell the server who to send the 
> message to.  After the RCPT commands is the 'DATA' command, indicating 
> the client is going to start sending the actual message.  If the DATA 
> command is received before any RCPT commands, an error is generated and 
> sent to the client.  To me it makes the most sense to do the state 
> management in the handler, so it's what is going to generate the error. 
>  As the current seda implementation is done, there is no way to inform 
> the decoder that the transition failed, so it will still be sitting 
> there waiting for data to come in.  I could implement the state machine 
> in the decoder, but that just doesn't make sense to me (seems like too 
> much work would be being shifted into that state and I'd still need to 
> do separate state management in the handler).  So what would be nice is 
> a way to put the state in a session and the decoder and handler could 
> communicate state information that way.
> Looking at the new protocol apis I see the method to get a decoder now 
> takes a Socket as a parameter.  So, I guess this is my vote and 
> reasoning to keep that in whatever apis we decide to move to after release.
> Just wanted to give my 2cents on the subject while it was on my mind, 
> hope I didn't ramble on too much. =P
> Rich

View raw message