Sunday, September 8. 2013
Phurple for PHP 5.3 and up
Shortly I needed an IM functionality in a small project. That turned me again to the Phurple project, the first PHP extension I ever wrote. What a pain was to look into the code written by myself about seven years ago 
. But it has worked, after three days work the phurple is PHP 5.3+ compatible.
. But it has worked, after three days work the phurple is PHP 5.3+ compatible.
The updated sources can be found on github. I made no release yet, would like to test (and it to be tested more) before. The next will be 0.5.0. Some updated documentation is still available here.
As the PHP 5.2 support was dropped, the class name you extend the Phurple\Client can now be arbitrary as the EG(called_scope) is used to determine the derivative class name. That also means it's now required to import or explicitly use the Phurple namespace as the 5.2 compatible class names (say PhurpleClient) aren't available anymore.
What I can say from the todays point looking at the 7 years old code of mine I don't get how one could code so lunatic. No, just kidding
From the todays point I can say - the libpurple is designed to be a real base for an IM client. It's designated to serve only one user per process. Despite that's a little disappointment for spammers, not really. The reason for that is that libpurple usual practice is to define global static variables for many things. They hold lists of accounts, buddies, etc. That's also why Phurple\Client class remains to work only as singleton and its constructor is final. Actually any program binding to libpurple has to behave as a normal desktop client, so one user - one process.
That's also why the phurple extension is only safe to use in the non thread safe environments. However it'll work with the thread safe version of PHP when the thread safety isn't utilized. Say the TS version is ok using CLI or FastCGI, but will behave unpredictable with Apache Worker MPM. Specifycally to mention is that Apache Prefork is totally fine to use, which is the case on most linux distributions with standard Apache/PHP packages. I personally would really recommend to use phurple only with NTS versions of PHP. And yes, nothing can be done about that without libpurple to be massively patched.
Anyway, enough jabbering
... a small usage example again
Please note that i'm not using a dsn and Client::addAccount() but creating an account object. That's not the obligatory way, however good to know it can work so. What is always useful when using not very widespread protocols is to try it with Pidgin first and take take the information the account.xml .
Also remark that I'm not using the manual iteration like in the previous examples, ->runLoop(). The runLoop() method runs the glib application loop of the libpurple, that will never exit so you need to break it manually somwhere you need in the custom class implementation.
That's it from my side. I hope to have some more time for this ext in the future. However would welcome any feedbacks, fixes and patches.
Thanks for the interest and enjoy. Nevertheless happy jabbering
As the PHP 5.2 support was dropped, the class name you extend the Phurple\Client can now be arbitrary as the EG(called_scope) is used to determine the derivative class name. That also means it's now required to import or explicitly use the Phurple namespace as the 5.2 compatible class names (say PhurpleClient) aren't available anymore.
What I can say from the todays point looking at the 7 years old code of mine I don't get how one could code so lunatic. No, just kidding
From the todays point I can say - the libpurple is designed to be a real base for an IM client. It's designated to serve only one user per process. Despite that's a little disappointment for spammers, not really. The reason for that is that libpurple usual practice is to define global static variables for many things. They hold lists of accounts, buddies, etc. That's also why Phurple\Client class remains to work only as singleton and its constructor is final. Actually any program binding to libpurple has to behave as a normal desktop client, so one user - one process.
That's also why the phurple extension is only safe to use in the non thread safe environments. However it'll work with the thread safe version of PHP when the thread safety isn't utilized. Say the TS version is ok using CLI or FastCGI, but will behave unpredictable with Apache Worker MPM. Specifycally to mention is that Apache Prefork is totally fine to use, which is the case on most linux distributions with standard Apache/PHP packages. I personally would really recommend to use phurple only with NTS versions of PHP. And yes, nothing can be done about that without libpurple to be massively patched.
Anyway, enough jabbering
... a small usage example againPHP:
<?php use Phurple\Client; use Phurple\Account; use Phurple\Conversation; use Phurple\Connection; class MyClient extends Client { protected function writeIM($conversation, $buddy, $message, $flags, $time) { if(Client::MESSAGE_RECV == $flags) { $name = $conversation->getName() ? $conversation->getName() : $buddy->getName(); printf( "(%s) %s %s: %s\n", $name, date("H:i:s", $time), is_object($buddy) ? $buddy->getAlias() : $buddy, $message ); } } } try { $user_dir = "/tmp/phphurple-test"; if(!file_exists($user_dir) || !is_dir($user_dir)) { mkdir($user_dir); } MyClient::setUserDir($user_dir); MyClient::setDebug(true); MyClient::setUiId("TestUI"); $client = MyClient::getInstance(); $account = new Account("my.account.name@gmail.com/Home", "xmpp"); $account->setPassword("mypass"); $account->set("connect_server", "talk.google.com"); $account->set("port", 5222); $account->setEnabled(true); $client->connect(); $client->runLoop(); } catch (Exception $e) { echo "[Phurple]: " . $e->getMessage() . "\n"; die(); }
Please note that i'm not using a dsn and Client::addAccount() but creating an account object. That's not the obligatory way, however good to know it can work so. What is always useful when using not very widespread protocols is to try it with Pidgin first and take take the information the account.xml .
Also remark that I'm not using the manual iteration like in the previous examples, ->runLoop(). The runLoop() method runs the glib application loop of the libpurple, that will never exit so you need to break it manually somwhere you need in the custom class implementation.
That's it from my side. I hope to have some more time for this ext in the future. However would welcome any feedbacks, fixes and patches.
Thanks for the interest and enjoy. Nevertheless happy jabbering
Trackbacks
Trackback specific URI for this entry
No Trackbacks