Now, I have been warned by our own local celebrity
merlyn that you have to be wary of turning into "every problem looks like a nail to me with my new shiny
hammer" guy. However, I have to admit that lately, 99% of the code that I've written I've been decomposing into state machines, and using POE as my "framework of choice." Though I definetly agree that if you can parse it using
thedamian's lovely Parse::RecDescent you probably should give that a whack, I've had lovely luck here as of late following a simple methodology.
- Break down problem into discrete states
- Define transitions between those states
- Implement states as a POE::Session
- Set up driver for dataflow as entry point into POE (in this case get the file pumping into the POE system)
- Lean back and enjoy your productivity
I understand that
POE is best suited for "interesting parallel problems", but I've learned that it's helped me with my thought process when it comes to defining state-machine(ish) problems. The only problem with POE is that it does have a rather high "barrier of entry" the first and second time you use it (it did for me), so if this is a problem on a timetable, you may not want to attack it with this particular hammer. If you do however, I can suggest no better starting point than
merlyn's excellent Linux Magazine column...
here...