On Fri, 13 May 2005, Brian Grossman wrote:
> It seems to me that can_read is a convenience function to allow folks like
> check_earlytalker to avoid splitting their handlers into top and bottom
> halves.
>
> Could we have a can_read_top that would do the setup and register a
> callback &code, and a can_read_bottom that would complete the handler? I
> suspect for that to work, the whole smtp session would have to be turned
> into a strict state transition table. That would probably mean expanding
> the definition of "event" to include anything that could cause a state
> transition. FD activity (as we have now), timed triggers, etc.
Yep, we are basically working towards POE, but without the overhead that
POE brings with it. I think ultimately I'm going to have to implement
timed triggers, as this will be the only way we can do can_read.
The way I see it, the check_early talker is going to have to work like
this:
- At connect, set a timer to fire in N seconds, and return DONE so the
core doesn't send a line to the client. Prevent the core from moving to
the 'cmd' state somehow.
- After the N seconds are up, check whether there's any data in
$self->{line}. Send the connect line at that time and move along in the
state machine.
Unfortunately this looks all a bit tricky. Someone mentioned earlier a
different type of return code. Something like CALLBACK that prevents the
state from moving on (and a response sent) until after a (provided)
callback returns something. And you check the callback every second or
so. But then I also don't want to do any kind of internal polling of a
callback function as that will kill performance. Dunno - I'm still
thinking about all of this as you can probably tell.
Matt.
