A couple of quick thoughts:
in reply to Data driven HTTP interaction
- The problem you are addressing is in spirit very, very similar to what Expect.pm addresses. The only difference is that you are communicating over an HTTP connection, whereas Expect communicates over a pseudoterminal. But both are based on a request/reply model.
- You describe this as "recursion", but to me it seems like that's an artifact of your implementation. You could just as well change either the description or implementation to a series of dependent request/reply transactions. (In general, it seems like the pattern is more of a graph than a tree. Any request could result in a "login timed out" reply, and the subsequent login request would be the same for a whole bunch of different original requests.) You could model it as a state machine, but I think a push-down automaton might be a better fit. Which itself makes me think of YACC -- perhaps its grammar input is a good model for a descriptive format?
- This also reminds me of Prolog. "My whole task is complete if I add a record for X, make sure the user permissions for Y are set up correctly, and I post an update to the news feed. Adding a record for X is complete if I look up "smurf livers" as a category, and I use that category to define..." etc. Using a similar reduction model, you might be able to figure out what things can be performed in parallel, or at least give nice error output: "Task A failed because subtask c2 failed."