Re: Design decision, call backs and network data

Use POE! It's meant for this kind of event driven programming. You fire off whatever request to get more info and note in your instance that you're waiting on requested information. Your got_traffic callback checks if you're expecting something or not when it receives a reply. You could even setup an alarm event that clears that state if you don't get a reply back after however long.

Comment on Re: Design decision, call backs and network data

Replies are listed 'Best First'.
Re^2: Design decision, call backs and network data by BUU (Prior) on Jul 25, 2004 at 19:23 UTC
Could you perhaps elaborate a bit? How would poe, and more specifically my "got_traffic" call back route the data, even if it knew I was requesting a response? What I have now I could just set a variable or object from my call back that says "requesting response", I'm just not sure what to do with the response.	[reply]
Re^3: Design decision, call backs and network data by Fletch (Bishop) on Jul 25, 2004 at 21:16 UTC
One way would be to create a separate session which handles (making something up here) "administrative requests". You specify that this session is in charge of sending and receiving any such requests. The main code posts a "get_frobnitz" event to the admin session. The admin session formulates and sends whatever request back through the communications handling session (or writes it directly to the socket's wheel). When the reply comes back an event's posted to the admin session which parses and handles it. The admin session could store the results in a shared location, or fire off another event (got_frobnitz) back to the original caller. At any rate take a look at any of the IRC related components and bots, as I'm sure they'd give you a better idea than my vague verbal handwaving above. :) IRC Bots Distributing Events, which might be of use (create a temporary handler which handles the returned data, and your communications handler fires it back when the reply is received).	[reply]


Don't ask to ask, just ask
	PerlMonks