Now that we know how to use DBus to communicate with Pidgin from PHP and how to listen to DBus signals, it's time to put it all together by creating a simple chat bot! Nothing fancy, just a simple script that runs somewhere on some server and, by using a Pidgin account, can respond to some basic queries we send it.

What did we get?

As we want our script to receive messages from an other account, first we need to listen to the ReceivedImMsg event on the im.pidgin.purple.PurpleInterface interface. The data we get with that event is the ID of receiver's account, the sender of the message, the actual message and the conversation's ID (and some flags which we're not interested in):

$interface = "im.pidgin.purple.PurpleInterface";
$method = "ReceivedImMsg";
if ($signal->matches($interface, $method)) {
    $data = $signal->getData()->getData();
    $receiver = $data[0];
    $sender = $data[1];
    $message = $data[2];
    $conversation = $data[3];
}

Of course, this is only for this one event, for data associated with other events see Pidgin's manual.

Who's there?

The event we are listening for will fire for any and all accounts, no matter who is the sender or the receiver of the message. We need to make sure that the receiving and the sending accounts are the correct ones, that the receiver is connected and that the receiver and the sender are contacts, "buddies":

if ($receiver == 2034 && $proxy->PurpleAccountIsConnected($receiver)
    && $proxy->PurpleFindBuddy($receiver, $sender) == 3681) {

The numbers 2034 and 3681 are the account IDs for my accounts I used in this example; you'll need to figure out yours.

Sending a response

Now that we know who's talking to whom, we can act upon the received message, do something with it, create a response message and send it back! The data we got with the event, has the ID of the conversation between the two accounts. We create a new instant message for that conversation and send it on it's merry way with our clever response message:

$im = $proxy->PurpleConvIm($conversation);
$proxy->PurpleConvImSend($im, $responseMessage);

As for what action the script can take upon a new message, is really up to the developer: it can do simple stuff like sending back the current uptime of the server or the current IP, running other tools like usher and sending that result back, or whatever is necessary.

Daemonizing

As this little bot is supposed to run on some server, the easiest way to run it as a "daemon" is to put the script in a background job via nohup:

$ nohup php chat.php &

If needed, creating daemons in PHP can be done too.

And that's about all what's needed to create a chat bot. See a complete example here on Github.

As for, is PHP the right tool for creating this kind of thing, I don't know, maybe, maybe not. What I do know, is that I had fun writing all this and I learned a lot along the way :)

Happy hackin'!

In my previous post I described (tried, at least) how to communicate with Pidgin from PHP, by using the Dbus PHP extension.

The good part is that not can we only call different methods against Pidgin's libpurple API, we can also listen to different signals on different events, that are sent via Dbus. Some of the events that are signalled are when a chat message is recieved, a friend comes online, a file is sent, or any other from a list of some 110 different events.

The PHP Dbus extension allows us to watch for one exact signal on an interface, or for all signals on an interface. Of course, we can add watches on multiple interfaces at once.

Watching for signals

Once we know the interface and/or the specific signal we're interested in, we can add a watch on it. This is done by calling the addWatch method on the Dbus object, were the first parameter is the interface, and the second, optional parameter is the exact signal we want to listen to.

<?php

$dbus = new Dbus(Dbus::BUS_SESSION);

// watching for a specific signal
$dbus->addWatch("im.pidgin.purple.PurpleInterface", "ReceivedImMsg");
// or watching on an entire interface
// $dbus->addWatch("im.pidgin.purple.PurpleInterface");
// also can listen to different interfaces at the same time
$dbus->addWatch("org.freedesktop.Hal.Device");

Next, we need a way to actually get these signals when the events occur. For this we are using the waitLoop method of the Dbus class. That method accepts a number as a parameter, which is the number of miliseconds it should wait between requests. If an event happened on the interface we're watching, it will return the signal, which is a DbusSignal; otherwise we'll get a null:

do {
    $signal = $dbus->waitLoop(1000);

    if ($signal instanceof DbusSignal) {
        // even if we watch only for one signal on one interface
        // we still can get rubbish, so making sure this is what we need
        if($signal->matches("im.pidgin.purple.PurpleInterface","ReceivedImMsg")){
            // data is in this weird DbusSet object thingy
            $data = $signal->getData()->getData();
            echo "Got stuff!\n";
        }
    }
} while (true);

Once we got the signal, to make sure that the signal is really the one we're interested in, we call the matches method on it. The first parameter is the interface and the second is the signal.

Each event has (can have? not sure yet) additional data associated with it. To get to it, for some odd reason, we need to call getData()->getData() on the signal; note that this is in case of listening on libpurple's interfaces, not sure about others. Experiment. Also, what kind of data is returned, again, depends on the interface and/or the event - some return arrays, some strings.

Have a look at the Github repo for some more examples (the dbus-signals* files).

In the third, and probably last post in this dbus mini-series, I'll try to build a bot with which I can communicate and issue out commands to.

Happy hackin'!

With Zend Framework 2 beta 1 released yesterday and some free time to spare, I decided to finally try and tackle one of the "scariest" additions to the Zend Framework - the EventManager component. Now, I won't go into details about this whole event voodoo, Matthew already did that. Twice.

Basically, this allows us to have one piece of code to trigger an event and to have one or more listeners listening to this event. When the event gets triggered, the listeners are called and then we can do *something*, like caching or logging. Logging or caching. Caching. Logging...

See, that's my problem. All the event examples stop at logging and caching. Truly there must be some other example for which this event stuff can be used for. (Yes, I know. The whole dispatch process is now event driven or whatnot in ZF2, but I need event examples in my application, not in the framework.) I don't claim I found a perfect example for the events, but I tried.

The problem

One of the most "repetitive" places in my code I found is the save method in my models. Pass an array of data to it, possibly do something with that data, validate it, persist it, maybe do some more data mangling, return true/false to the caller. Over and over again, but just with enough difference between different models that there is actually no double code to pull out to an abstract class or some such.

Say, for example, we have a Post of some sort. It has a title and a slug created from the title. Standard stuff, nothing fancy. For the Post to be valid, it needs to have both the title and the slug set.

Now, without the EventManager, the save method could have a similar flow:

• call the save method, passing in the data array
• check if the data array has a slug set, if not, create one from the title
• validate the data array, to make sure both title and slug are properly set
• save the post

As I said, pretty standard stuff, so I'll assume you can imagine that piece of code in your head (read, I'm lazy to write it). The problem: the save method is stuffed with data preparing and validation code.

Using the EventManager

This is where, I hope, the EventManager can help. Call the save method and, just before the persist call, trigger a "pre-save" event and then persist the data. Attach two listeners to this "pre-save" event; the first will do the data preparation, the second will do the validation. There, done. Now the save method doesn't have that unneeded code around it and can be pulled out to an abstract class, all that is in the event listeners.

Let's see some code:

<?php

// This is the Post object

class Post
{
    protected $events = null;

    public function events()
    {
        if ($this->events === null) {
            $this->events = new Zend\EventManager\EventManager(__CLASS__);

            $this->events->attach('save', array('SlugifyPost', 'slugify'), 100);
            $this->events->attach('save', array('ValidatePost', 'validate'), 90);
        }

        return $this->events;
    }

    // this method can be pulled out to an abstract model class
    // and reuse it for all the models that extend it
    public function save($data)
    {
        $this->events()->prepareArgs($data);
        $response = $this->events()->trigger('save', $this, $data);

        echo 'data saved! ' . json_encode($response->last());
    }
}

I just set a "save" event to be triggered and attached two listeners to that event, the slugify and the validate methods. When the save method gets called, the event is triggered and the EventManager calls our listeners. One fairly important point here is the prepareArgs method call, which prepares the event arguments in such way, that when these arguments (the $data array in this case) are modified in one listener, this modification is reflected for the other listeners, too. If you don't want to modify the arguments in the listeners, this call can be omitted. As for the rest of the code, it's explained in Matthew's posts and in the ZF2 docs.

And here's how the slugify method modifies the data:

<?php

class SlugifyPost
{
    public function slugify($event)
    {
        $data = $event->getParams();

        $event->setParam('slug', strtolower(str_replace(' ', '-', $data['title'])));

        return $data;
    }
}

Calling the save method itself remains as it was before introducing the EventManager, which means I could add this to my models without changing the API and not break anything! Genius! Theoretically, anyway...

<?php

$post = new Post;

$values = array(
    'title' => 'My post'
);

try {
    $post->save($values);
} catch(\InvalidArgumentException $e) {
    echo $e->getMessage();
}

You can find this complete example on Github.

Thoughts?

So, what do you think? Does this approach makes sense to you? Do tell. I kinda like the idea, but time will tell in the end, as always.

Happy hackin'!