The scary thing about POE, at least to me, is that it is rather embryonic, and is apt to change quickly....building your app on a POE dependancy (POE will tend to change the architecture of your whole app) may be a problem if you download a later version of POE and things are different. Or if you want to start programming in a non-POE style.

That's a strange way to look at things. POE's users get at least two months' notice on compatibility breaking changes. In practice, public interfaces are slowly broken over the course of at least a year, with posted notices, documentation changes, and warnings before the old way is prohibited outright.

Please see POE's posted guidelines for compatibility breakage.

For cases in point, see the deprecation of a public parameter style and the rewrite of POE's signal handling semantics. Both were started over a year ago, and both are still in progress.

All the cool kids subscribe to POE's mailing list if they're using it in mission critical applications and absolutely need to stay on top of developments.

If you do adopt the POE approach, I'd at least encapsulate the engine somewhat so you can swap it out later without too much pain.

I recommend the inverse, but it has the same outcome.

New POE users tend to go overboard with events, using them where plain method calls work better. The result is a lot more overhead than necessary, and people become disappointed when they decide "POE is too slow!"

Separating the application from POE leads to cleaner and faster code. Fewer methods become event handlers, and fewer method calls incur the latency of being queued at events. And like you say, with the application and events separated into layers, either is replaceable without adversely affecting the other. It's all good.

-- Rocco Caputo - rcaputo@pobox.com - poe.perl.org