I suggest using some kind of automaton. Most types can handle looping and branching, and if they get extended or can run code or store data they are powerful enough. Creating yet another way is probably not good for the learning curve you talked about. You do not really need a new session type. More than one automaton per session might be useful, so that you can have several active threads of event handling. The decision between (wheel-reinventing?) shortcuts and full solutions might not be that easy, especially for a general how-to. Shortcuts are hard to extend, and if the protocols get slightly complex the automaton you selected might not be sufficient anymore. Concurrency between handlers has as well to be handled, so you might need to lock some steps and stuff like that. You could use Petri nets as well. The example you gave with the n-steps of a function might look like:
(event-listener) -> [step1] -> (step2 args) -> [step2] ... -> [step n] () are places, and [] are transitions using my coloured Petri net implementation you could either use the graph editor or write a simple hash describing the net. So it either gives you a good graphical presentation of complex nets or a short and easy to write/read code presentation. Several other problems like loops, branches, producer-consumer, ... can be easily modelled with Petri nets. If shown as graph its far more readable than code-based approaches. The editor is almost usable. Until I know more about Java and Swing there wont be big steps, but Java is actually better than I thought ;) After that I hope to see first contact soon (between the Perl module and the Java editor) so that one can start writing (and testing!) nets. If someone is interested in contributing (especially on the java side :) please tell me. Torvald
