Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: Data driven HTTP interaction

by sfink (Deacon)
on Jul 23, 2007 at 05:15 UTC ( #628177=note: print w/ replies, xml ) Need Help??


in reply to Data driven HTTP interaction

A couple of quick thoughts:

  • 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."


Comment on Re: Data driven HTTP interaction
Re^2: Data driven HTTP interaction
by revdiablo (Prior) on Jul 24, 2007 at 01:37 UTC

    Many thanks for the reply. I'm glad to see you've looked beyond the specific implementation. Your ideas are certainly worth thought.

    I will almost certainly play with the idea in your 2nd point. I may be painting myself into a corner with my current recursive implementation. Your idea seems a lot more flexible, and will probably lead to definitions that are simpler to understand (at least for some definition of "understand").

    I must admit the Prolog-esque solution sounds like a lot of fun. I'm not sure it would be worth the conceptual hurdle, but then again, maybe it would! Hmm.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://628177]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (11)
As of 2014-10-23 16:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (126 votes), past polls