Of division of roles

The most recent release POEx::Role::SessionInstantiation now breaks out all of the various aspects of its inner workings into roles that are then composed into the master role. And now, via import, we can tell SessionInstantiation to compose other roles. It was a big refactor. But what did it buy? In terms of customization, it bought a lot.

The various segments were placed under POEx::Role::SessionInstantiation::Meta::Session::*. And so there is now Events, Implementation, Sugar, and Magic.

Events contains the various default events that POE would deliver to Sessions. Implementation takes care of the details of event dispatching and registration. Sugar provides methods that are delegated to the POE::Kernel singleton. And finally, Magic handles the tricky bits of making it all work with POE.

So now that everything is divided we can do some nifty things with the resulting roles. Let's say we wanted to build our objects without telling POE about them. All of that functionality is now stored inside Magic. It is simply a matter of advising the the BUILD method to not call session_alloc on the kernel instance. In fact, that functionality is now bundled up as POEx::Trait::DeferredRegistration.

And what if we wanted to do some initialization not specified in _start, but at that time from an external source? We can consume the Events role and advise _start as necessary. And this functionality is wrapped up in POEx::Trait::ExtraInitialization. It requires an arbitrary coderef at construction time that will be called as a method on the session at _start.

Now most of this was possible without the big refactor, but it would have been making use of under documented features inside SessionInstantiation. Now all of the bits and pieces have their docs and are segregated appropriately to allow for easier customization.

So what can you do with those kinds of traits? Aside from building better tools to manage resource sensitive operations such as loading modules before or after a fork, it will also eventually help with furthering POEx::ProxySession.

There is more to do on the Moose/Class::MOP front to finally make it possible to serialize in total a session, send it somewhere, reconstitute it, and activate it in the foreign POE kernel, but this is good step in that direction.