POE Hackathon

Chris BinGOs Williams

POEvangelist

KUDOS

• Rocco Caputo for creating POE
• Merijn Broeren for the "POE Field Guide"
• All the POEvangelists out there
• You lot for turning up, thanks!

Who the hell is this guy?

• By day, a Network Services Specialist
• By night, perl hacker and POEvangelist
• CPAN ID and IRC nickname, 'BinGOs'
• Using perl since 1995
• Using POE since 2003

So, Who the hell are you guys?

• Name ?
• CPAN ID or IRC nickname ?
• Perl experience ?
• Used POE ?
• Interested in doing what with it ?

What Is POE?

• The "Perl Object Environment"
• A framework for event driven state machines
• "Pure Perl"
• Cooperative "Threading"
• Written in layers with varying levels of abstraction

Why POE?

• Programming is all about abstraction
• POE is an abstraction that makes certain classes of programming easier
  • Network Applications
  • Applications with long-running system calls
  • Daemons and other long-running applications
  • Finite State Machines
  • Applications that must deal with signals or external events
• POE is the most fun you can have with your clothes on
• ...or off, your choice

POE? Huh! What is it good for?

• Network clients and servers
  • Web clients and servers
  • IRC bots
  • IM bots
  • Email clients and servers
  • etc.
• Integration with GUI toolkit event loops
• Network monitoring
• Long running processes involving scheduling
• Blah blah blah >;]

POE::Kernel

POE::Kernel

• An event application kernel
  • cooperative timeslice process module
  • provides event loop services to POE::Sessions
  • comes with its own event loop based on select()
  • cooperates with four external event loops "out of the box": Gtk, Tk, Event or IO::Poll
  • other POE::Loops available on CPAN: Wx, Kqueue and Glib
• Event services provided by kernel methods
  • FIFO and Synchronous Events
  • Delayed Events ( and alarms )
  • Filehandle Watchers ( Selects ) and Signal Watchers
  • State Management and Reference Counts
• Runs until there are no more events to handle

POE::Session

POE::Session

• Event driven abstract state machines that encapsulate tasks
• Bundles of states
• States are registered subroutines or methods
• Sessions have resources: a heap, events, filehandles, child sessions and aliases
• Sessions have unique IDs and have a symbolic name 'alias'
• Kept 'alive' while they have something to do
  • Have events pending or delayed events
  • Have a symbolic name ( alias ) registered
  • Have active filehandles
  • Have extra references

States

• Three types:
  • inline - coderefs
  • object - methods
  • package - methods/functions
• Declared at session creation
• Or "on the fly" using Kernels state() method
• States should "return" as quickly as possible
• Don't block, mmmkay

Predefined States

• _start
  • Called as soon as the session is created
  • Used for naming a session (aliasing), initiating a loop, creating network connections, opening files, etc
• _stop
  • Called when a session has run out of things to do and is being garbage collected
• _child
  • Called when create, gain or lose a child session
• _parent
  • Called to inform a child session of new parentage

Predefined States

• _default
  • If defined will catch "unhandled events"
  • Make sure to 'return 0;' so as not to affect signals

States and Context

• State handlers can handle different states for different sessions
• Always provided with the context via parameters:
• A reference to POE's kernel instance.
• A reference to the session's storage space ( the heap ).
• A reference to the session itself.
• A reference to the session that created the event
• The start of the event's parameter list.
• Array slice of the @_ array:
  • using POE constants: KERNEL, HEAP, SESSION, STATE, SENDER, OBJECT
  • Alternative methods error-prone and not future-proof

POE::Wheels

POE::Wheels

• Wheels are POE's I/O abstraction layer
• Bundle of event handlers
• Created by sessions to mutate their behaviour
• Must be stored away in the heap or they "disappear"
• Some prefabricated Wheels come with POE:
  • SocketFactory - Non-blocking socket creation
  • ListenAccept - accept connections from regular listening sockets
  • ReadWrite - buffered non-blocking IO
  • ReadLine - terminal input with editing
  • Run - spawn child process with non-blocking communication

POE::Drivers

POE::Drivers

• Implement generic interfaces to low-level file I/O
• Used by POE::Wheels to read and write files, sockets, etc.
• Currently only POE::Driver::SysRW

POE::Filters

POE::Filters

• Implement generic interfaces to low- and medium-level protocols
• Turn raw bytes into something useful
• Objects that support put() and get()
• Should sub-class POE::Filter
• Can be switched in Wheels
• Can be "stacked" using POE::Filter::Stackable

POE::Components

POE::Components

• Components generally encapsulate functionality in a session
• Consist of a session, wheels and filters
• Usually provide services to other sessions and components
• POE::Component namespace exists for publication of components
• Currently 210 "PoCo" distributions on CPAN
• POE ships with two components:
  • POE::Component::Client::TCP
  • POE::Component::Server::TCP

POE::Components

• POE::Component::Client::DNS
• POE::Component::Client::HTTP
• POE::Component::EasyDBI
• POE::Component::Client::SMTP
• POE::Component::IKC
• POE::Component::Generic

POE::Tricks

Are you my mommy ?

• Sessions can have child sessions
• So who is our parent?
• And who are our children?
• _parent and _child states tell us this
• And SENDER in a child session's _start will be the parent
• 'root sessions have KERNEL == SENDER in their _start

Where there's a wheel there is a way

• POE::Wheel::Run spawns child processes
• Can also fork() code references
• Arguments are passed to @_ in the coderef
• fork off bits of long-running code
• This is very cool
• POE::Component::Generic takes this further
• provides a non-blocking wrapper around any object