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.

Murmur, DBus and Perl

Short post this week, but a neat project came up that I want to throw together this weekend.

Some quick background. Murmur is a VoIP server. Its typical application is use with the Mumble client to provide voice communications for computer games in the same vein as Ventrillo or Teamspeak. Together it provides a great set of features that include encryption, distinct channels, ACLs similar to IRC, and even user accounts. It is also useful for conference voice communication that provides superior voice quality than that of Skype or even conventional telephone conference calls that tend to be half-duplex.

So what does that have to do with DBus or Perl?

Well, Murmur's configuration all happens via DBus. DBus comes with a CLI app to sending arbitrary data along the bus properly addressed to a listening daemon. And just to add a user to Murmur the length of the command is unwieldy. In fact, you have to send two commands to set the password. You can do all sorts of configuration via DBus, but it is pretty hairy having to do it by hand.

So enter Perl. CPAN has a module called Net::DBus. So I am going to write a set of tools to administer Murmur and publish to CPAN under the App:: namespace.

Lots of good modules to use to make that happen including Moose, MooseX::Getopt, App::Cmd, etc.

By Sunday evening, I should hopefully have something that works (with stand alone libs that could be consumed via GUI app) and we can work on refinements from there.

You'll see the repo show up github soonish.

TryCatch + Throwable rocks

I hopped on the bandwagon a while ago since I started using these two modules in my own projects so I could have real live try/catch blocks including MyError->throw(). As a bonus I get constraint matching on which catch block to execute.

Lots of people have pushing the Try::Tiny that Yuval put together and that's cool too, but I like my constraint matching. I have had several cases where it makes sense to do different things based on the type of exception I have received. And, I do enjoy having the lexicals put into my scope too.

For me, since I am already using MooseX::Declare which uses MooseX::Method::Signatures which uses Parse::Method::Signatures, it is a natural extension that my catch constraints be defined with the same syntax.

Recently though, I ran into a bug in TryCatch regarding certain scenarios with returns inside the try block. I banged my head against the wall for a day or so to no avail until I manned up and asked Ash what was going on. And much to my delighted surprise, it was already a reported issue and already fixed in a dev release on CPAN. I pulled it down and ran my tests and magically everything started working.

Anyhow, what prompted all of this was my work on POEx::WorkerPool. In my first go around, I wrapped a lot of the potential error spots in try/catch blocks but some of the handling was inconsistent, so I wanted to go back and rework a lot of that to be even more robust.

Now when errors occur, signals are handled properly inside of POE, and are reported via PubSub. For the most part, catastrophic errors are mitigated and reported instead of taking the whole enchilada down into some horrible state.

As soon as Ash does a non-dev release of TryCatch, I'll do another release of POEx::WorkerPool that includes this new found robustness.

New Shiny

This past week I've been slammed; working to produce a new module: POEx::WorkerPool. Now, this will probably smack of NIH, but I looked at a couple of other good modules such as MooseX::Workers, and decided that I need to do my own that made use of the POEx tool chain and included MooseX::Declare.

To that end, the POEx::WorkerPool does the usual multi-process management and provides a mechanism to dole out jobs to workers, but where I feel it provides more bang for you buck is highlighted below.

-Easier Customization-
Each piece in the framework can be customized via traits defined in the 'use' statements of those pieces. Each piece does light coupling via Roles checking, so it doesn't hinder customization.

-Transparent Workers-
Workers publish a plethora of events via POEx::PubSub that allow for tracking of a job from the time the worker starts processing to even incremental progress updates

-Rudimentary Priority Modes-
Worker availability is effected by a two different modes: round_robin and fill_up. In round_robin mode, the next available worker is gathered in your typical round_robin fashion. And in fill_up mode, the same worker will continue to be gathered until it's work queue is full.

-Abstract Jobs-
The simple Job Role provides a light shell for whatever needs to be processed, but at the same time giving the framework some consistency for reporting progress, and identification.

And while those things are awesome, there is still room for improvement down the road. The API could be expanded a little further in the WorkerPool itself with regards to how the jobs get delivered. So there will be future releases as I work more on it.