POE: Perl Object Environment.

15 Minute Lightning (and thunder) talk - Steve McNabb

Toronto Perl Mongers - 30 Aug 2001

steve@justsomeguy.com

--
What is POE?

From the offical POE homepage at http://poe.perl.org,

* "POE is a framework for <i>event driven state machines.</i>"
* it was written by Rocco Caputo.
* originally written to manage a MUD
* provides a set of tools for managing multiple state
  machines.
* POE is 3 years old - nice and stable  
* effectively provides cooperative multitasking in perl
* won "best new module" award at TPC 3.0

--
A What Machine?

What is a state machine?

* sometimes called 'finite state automata'
* consist of states and transitions
* state:  things like "waiting for bus", "paying fare", 
  "chatting with the person next to me on the bus"
* transition: "done waiting for the bus. now go up and pay the fare"
  or "stop chatting with person next to me, start staring out the window"

Ascii Fu:
<pre>
...........                               ........... 
| State 1 | -=> transition to state 2 -=> | State 2 |
...........                               ...........  
     ^                                         |
     |                                         | 
     |- transition back to state 1             |- transition to state 3
     |                                         V 
...........                              ............
| State 4 | <=- transition to state 4 <=-| State 3  |
...........                              ............
</pre>

--
An Example:

A simple example would be something like a door.  The door
only really has three possible 'states':

* open
* closed
* partially open (or partially closed if you're a pessimist)

and there would be a transition from each state to each other
relevant state.  

* door is closed.  begin opening  
* door is partially open, continue opening 
* door is still partially open, continue closing
* door is open, begin closing
* do nothing - leave the door alone
--
The plot thickens:

POE does cooperative multitasking - in pure perl.  This means
that each 'Session' (loosely analagous to an operating system 
process) must cooperate,  and offer control of the CPU to other sessions 
as long as its around.  This means (ideally) everyone plays nicely,
and no one session hogs the CPU. 

This also means you can have lots of individual sessions clicking along
and the POE kernel will divide up the available CPU resources among
each session, and make sure each session gets its piece of the
processing pie.
--
Think of it like a mini operating system - in perl.

That's what your operating system does: it handles requests for
resources from multiple processes at once, and (hopefully) 
keep processes from colliding with one another.

* POE is very featureful.

POE has 
<ul>
* a kernel: the object in charge  
* sessions: (sort of like processes, but all of these exist within the same perl process!)
* states:  states recieve events - either the built-in ones, like _start and _stop or user-supplied
  events like "get_status" or "add_three_numbers" for example.
* sessions:  sessions are like mini applications - they're the part of POE that gets stuff done
* filters:  man(gles|unges) input/output ala stream filters
* wheels:  pass data between sockets and sessions through filters
</ul>

Cool huh?  We're only going to talk about the kernel, sessions and states for now.
--
So what's it good for?

Well, anything that has to do with loops would probably be a good
candidate for POE-ification.  POE already has support for Tk and Gtk
loop constructs for example.

One of the areas in which POE has been most widely (used|abused) is
in network clients and servers.  POE already has existing component
support for TCP, DNS, HTTP, ICMP, IRC, RSS, XML-RPC, and SSH, SLL 
and others are in the works.

There are also POE components for:
<ul>
* asynchronous audio input and output
* POE::Component::Client::UserAgent 
* interaction with the festival speech synthesis engine
* interacting with MPG123 (a unix mp3 player)
* POE::Component::SPX - interact with the sphinx speech recognition engine
</ul>

There's even a suite of modules called POE::Component::SubWrapper that purport
to automagically wrap normal subroutines in POE stubs - so you could just do 

> poeize Some::Module::WeLike  

but, having never used these modules myself, i have no idea how well 
they work.
--
The punchline

Not only can you have multiple sessions running at the same time within
the POE kernel, you can also have mutliple kernels running at the same time!

Using Phillip 'Leolo' Gwyn's POE::Component::IKC (inter-kernel communication)
you can have multiple kernels running at the same time, passing events and data back
and forth. 
<br>
<img src="crazymap.gif">
<br>

Neat huh?  

--
The punchline - continued.

Since the inter-kernel communications module is inherently network-based, you
can use poe to write network-distributed parallel processing applications.

You could write your own distributed.net cryptography cracker or seti@home type
application: take advantage of many POE kernels all running on different machines
all at the same time, and make your very own perl/POE-driven network distributed
supercomputer.  

eeikes.
--
The code

As with most things perl-ish, there is way more than one way to do it.  In this
particular example, I'm only going to focus on POE's "object sessions" 

What we need:
<ul>
* an object for each kind of session we will want.  in this case, we'll have two
  different objects:
  <ul> 
  *  master - this object is in charge of getting things moving, and running the show.
  *  flunkie - this object does the work while the master eats donuts
  </ul>
  * a little POE code to set up the master session, and to start the POE kernel running
</ul>
--
Example Code - a campy, toy program

<a href="example_code.perl">Example Code</a>
<p>
<a href="sample_output.txt">Sample Output</a> (in case we don't have POE on the display machine)



Questions?

--