use Perl

(Sorry for the massive delay in posting)

I don't know if I'll keep up the $num_of_exclamation_marks = $no_of_part title thing, but this subject is perhaps the hardest thing to understand when approaching POE. If you heard about event-based programming, and you figure "okay that's simple enough, I get it" then you probably don't!

The problem is that even though we figure it's a pretty basic concept (and really, it is), it's harder to understand what it means. What it really means is that you need to think differently. Understanding the idea vs. thinking differently.

Anyway, event-based programming is basically saying that a function is called only when an event happens, and not because the next line of code has been issued. You define events and what happens when an event occurs. That's when callbacks become useful. You can define that if the event falling_off_the_chair happens, you provide a callback (AKA code reference) to sub { print "hahaha\n"; } .

An example would help understand better:
Imagine a web server. The web server takes requests from browsers (or rather, clients) that want certain pages. It listens for incoming connections and whenever a connection arrives, he asks them "What the $@#* do you want?" and they say "give me that $!#%&*^ page over there!" and he goes to get the page, when he gets there, he (the server) gives the client the page and says "here you go, now take it and shove it up your %!@" and closes the connection to him. Web serving is a very violent profession, as you can tell.

Looking at the example, we see several events (and a few places to get counseling), which are:

• a connection was made - a client connected to our socket
• a request by that client was made
• after being asked for a page, we try and reach it - reaching it is an event
• the client confirming that he got the page
• the connection closes

In event-based programming, we set up functions (either as subroutines at the top/bottom or straight away as anonymous subroutines) and then we set up whatever listens and provide it with references to the subroutines we wrote in case of certain events.

For the webserver, we'll have to write small functions in certain cases:

sub incoming_client {
    my $client = shift;
    print_to_client( $client, "yo yo yo. what page will you be askingz for?" );
}

sub asked_for_page {
    my ( $client, $request ) = @_;
    my $page = get_page($request);
    give_client_the_page( $client, $page );
}

sub accept_thankyou {
    my $client = shift;
    print_to_client( $client, "no, thank you!\n" );
}

Now this won't help us much if no one is going to be waiting for incoming connections, right? So we need to set up a TCP server, that accepts connections and forwards it according to the event. Obviously, the TCP server will have to understand what each event means. For example, if a client sends (using HTTP) a code that requests a file, our TCP server will need to say "oh oh, it's trying to get a file, I'll forward it to the correct subroutine". So, we'll use the fictional TCP server Sawyers::TCP::Server::That::Understands::HTTP. Yes, I like lots of namespaces. Dont::Event::Get::Me::Started.

This is the code for starting the TCP server and telling it what to do in any event:

use Sawyers::TCP::Server::That::Understands::HTTP;

my $server = Sawyers::TCP::Server::That::Understands::HTTP;
$server->set_up_events( {
    incoming_connection => \&incoming_client,
    incoming_request    => \&asked_for_page,
    closing_connection  => \&accept_thankyou,
    echo_hello          => sub { print "hi!\n"; },
} );

$server->start;

print "yay!\n";

Now, the trick here is that any code that comes after the $server->start won't be executed. Why? Simple, because $server will be running forever. Keeps an open connection and keeps waiting for events. So, there is really very little point waiting for the "yay" line, because it won't be there. Unless we set up an event that closes $server and when it will be closed, the remaining lines of code will run.

Any questions?