I have an application which I am trying to use POE for. The first part was simple: change a pre-forking socket server into a pre-forking POE server. A good beginners test.
My application already has a lot of functionality built into various different packages. For example, I have a package called MySession and I make a single instance of this package which ties a lot of other packages together for the duration of the application.
Creating a MySession package will create a MyDataManager package and a MyDispatcher package. I currently store references on the MySession object so that I can access these using $mysession->{mydatamanager} and $mysession->{mydispatcher}. Nothing special there.
This is how I would start to translate this to POE: I would have a POE::Session object for MySession, and POE::Session objects for MyDataManager and MyDispatcher. by aliasing these last two, they will persist as interfaces that I can send events to. No need to store references on MySession because I can call/post/yield to the alias. Am I right, so far?
My next point of confusion: does it go against POE thinking to use "call" over "post"/"yield" for the majority of events? The reason I ask is as follows: the MyDataManager package exists as an interface whose methods are called from other interfaces in such ways as "what is the answer to such and such variable?". It seems that I would never "post" an event to MyDataManager but would always use "call", as the calling interface would need the answer immediately before being able to proceed.
Finally, another thing on my mind is how I wrap existing packages with a POE interface that exposes their existing methods without too much modification.
The approach I am most likely to take is this: a package, for example MyDataManager, will remain unchanged. I will define a new package called POE::MyDataManager which will create a POE::Session and an instance of MyDataManager which is stored on the session heap. The events handled by POE::MyDataManager will call the existing methods on the heap's MyDataManager and return the result. Ultimately, a POE event to object method handler, which should allow me to continue to use these objects in a non-POE environment.
What this all says to me is that I would be using POE to manage sessions that can send events to one another but I wouldn't get any of the multi-tasking functionality (as I am usually sending events to the top of the queue with "call"). I do have an interesting loop within the application that I want to tackle using POE events, which itself is the biggest reason I am trying to integrate POE. Is there anything glaringly wrong about the other approaches described above?
Regards, /dave
