On Sun, May 16, 2004 at 02:17:12PM -0400, Lincoln A. Baxter wrote: > > Lets talk about POE. With POE we have a suite of packages whose scope > and breath is not unlike what we have put together with GIP. > > Infact when we started originially, we looked at POE. At that point > we considered it not quite what we were looking for. On reviewing it > again recently, we find it's now got GREAT documentation, an impressive > following, and much more maturity, but its still not suitable for some > of the things we have been doing. For instance, core to the POE module > at least for implementing servers is the interfaces must support unix > select(). We needed MQSeries.
> Our Framework can be used to solve many the same kinds of problems > that POE solves, but it is more generic in its use of interfaces. > POE services assume that request interfaces implement IP socket > semantics, supporting the use for the unix select() function. I'd be surprised if POE couldn't be made to play nicely with MQSeries. It's all kinds of flexible these days. POE doesn't rely on select() for its event dispatcher. It can use anything that multiplexes I/O and provides a timeout. The dispatcher interface is documented in POE::Loop, and the distribution already includes implementations for select(), IO::Poll, Event, Gtk, and Tk. It sounds like a low-level MQSeries event queue would be needed in addition to an event dispatcher. That's also possible. POE::Queue documents POE's generic event queue plugin interface. There is only one plugin so far, so the interface is still subject to change. What do you need? >From my admittedly cursory readings on MQSeries, it sounds more appropriate for interprocess message passing than for low-level event queuing and dispatching. That is, a POE application might use its internal queue for local things and an MQSeries transport for passing messages to remote places. POE provides all the tools for interprocess message passing, but it doesn't enforce a standard method. At least one third-party transport, POE::Component::IKC, has been created to fill this void. Others are possible. Generally speaking, anything with an exposed filehandle can be plugged into a POE program using its low-level select_read() method. Even without an exposed filehandle, it is theoretically possible to wait for things in separate threads and inject incoming messages into POE's intraprocess queue. POE::Resource mixin classes can be created to manage these watchers and their threads, and POE::API mixins can expose the mechanics through friendly public interfaces. I say "theoretically" because these concepts are some of the newest introduced to POE, and their proofs haven't yet been implemented. They are desirable features, however, and POE developers would assist anyone wanting to add them. > Logically atleast, existing Framesworks _could_ be migrated to > Framework:: as well (although I don't really expect that to happen). > > Framework::POE (currently POE::) > Framework::Wombat:: (currently Wombat::) > Framework::POEST:: (currently POEST::) > Framework::NetServer:: (currently NetServer::) > etc As sensible as this is, I don't expect it to happen either. In fact, I would resist it. Revising, retesting, and redeploying POE based systems would cost thousands of man hours. A lot of people would be upset if they had to do it just for a name change. -- Rocco Caputo - http://poe.perl.org/
