directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <rwall...@thewallacepack.net>
Subject [seda] Session acces in the decoder
Date Fri, 17 Dec 2004 17:19:12 GMT
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

Mime
View raw message