[...]
If you're really only storing data, you really should use an object OR package in the ways I mentioned above. Atleast, if you have any desire to maintain efficiency.
Now here I must note, that I didn't come up with the idea of removing inter-session calling all together. I found the idea on the wiki. Now I'm not gonna name names, and I'm not gonna drag others in, because I am a proponent of the idea. I think inter-session calling breaks POE Design patterns. Forcing inter-session communication to be done via post()ing helps force people using the POE Framework to let POE do its thing, and stops people from doing things like creating sessions just for the sake of creating sessions.
I also have a need for inter-session calling, so I want to add my tuppence into this :-). Hopefully, my description below isn't so abstract to be non-sensical, but will convey why I need it.
I have a fairly complex system that runs various background monitoring tasks (using Wheel::Run) and also takes in requests from the network. Each new network request gains its own session for it to process all work. This work may take some time, also creating new Wheel::Runs, etc. The effect of some of the requests needs to change the frequency of the background monitoring that's going on, or needs to change some of the 'global' data that dictates the manner in which the background processing is run. There is no synchronisation/locking of global data, so the only way to do that is to ask the session owner to make the change. When that type of event happens, we need to get a cross-session event to take place. We can't use post() all the time, because sometimes we need to ensure that the change happens before anything else in the queue is fired off, else we get out-of-order processing. It's a rare thing (only need this twice, in a codebase of ~20k lines of perl), but it does happen. I cannot see (within the constraints of our architecture) how I can achieve this without inter-session call functionality.
Nick.
