Why mess with perfection? Go with what you've got if it works and you don't need anything else.

If you're still curious about POE, see POE's cookbook. It has a few server examples, as well as one or two that spawn worker processes.

By the way, how do you multiplex pipes and SysV message queues?

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

Well, I haven't written it yet. I'm just finishing up the design now. As for multiplesing pipes and SysV messages, I'm planning on using select to handle the pipes (with a timeout), and poll the message queue with the non-blocking bit set.

I'm happy I didn't overlook some multiplex magic with SysV queues, but I'm also sad that one doesn't exist.

If you're already familiar with select(), there's a tutorial for select() users that might help you decide if POE's worth your while.

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

What you want to do sounds like it would work with POE just fine. You'd just have to use POE::Wheel::Run to execute the program, and set up events that get triggered when the program outputs anything. It's all very straightforward.

Contrary to flyingmoose's long and thoughtful post, I think POE make things much simpler, as long as you're doing something that POE is good at. For instance, the thought of "manually" writing a program that does fork/exec, then subsequently opens a socket and waits for commands to come in on the socket, which are then relayed to the external program... Just sounds like a nightmare. POE would make this relatively easy.

I'd say at least give it a try. POE::Wheel::Run is quite easy to use, and if you have any specific questions once you start using it, we can of course help you here at the Monastery. 8^)

I guess it depends on what domain you are coming from -- or developing software for. I did not mean to imply POE doesn't have it's place. Some of the IKC and timed event stuff looked pretty interesting to me. I don't like, however, how it has to use the wheels and filter to replace things most folks are used to...So it has plusses and minuses to me.

In general, I wish it much success. It is certaintly very shiny to look at... but like any large scale stuff, it makes things too compilicated if applied to small scale projects :) The comments rocco made about not over-indulging in events is right on -- that's the trap I fell into -- it sort of became self-obfuscating for code that should have been straightforward.

I'd like to see some philosophical discussion on how to "code POE in the style it was intended", but that's better suited for the Meditation section. Having some stylistic guides to programs significantly more complex than the material included in the POE cookbook would be much appreciated -- i.e. coordinating lots of interlocked things rather than dealing with one or two GUI components at a time. You know, insanely complicated middleware kind of stuff...

Anyhow, in every medium (working on cars, whatever) -- there are some things you want to think about as a black box and other areas where you want the gory details. Chosing whether or not to use POE has a lot to do with how much you want to be in control of that particular detail. RAD or fine-tuning.

POE is very nice, I do not intend to knock it...it's just a little funky and tends to shake things up a bit. (Which can often be a good thing!)

Maybe. Depends on how big the app is and how fast you can fix it if POE doesn't turn out like you want it.

In my opinion, POE looks cool, but it doesn't always make things simpler. Posting events and writing in an explicit event-driven style can be very counter-intuitive when compared with other styles of programming (i.e. functional, imperative, OO, and a mixture of those). It complicates debugging.

I will say, though, that POE is taking quite a following and has some very good Component modules that may make going to this format worthwhile. For me, though, I'd rather write my own event loops and callbacks...just to keep the code simple and more debuggable. This is not for all folks, that's just the way I like it.

Sometimes a good reason to use POE is because the POE modules are better than the non-POE alternatives. i.e. POE::Component::IRC is probably the best IRC module out there. But, even then, it might make since to use POE only so far as to enable use of the module.

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.

I'd vote for doing things the same old way (methods and loops), but use a few modules to control your processes and their inputs and outputs. There are other modules out there for starting and checking on processes, etc. 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.

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