In a recent post to his site Piotr Pasich shares an article about using a rabbit behind the scenes - making use of the RabbitMQ queuing system for behind the scenes work in your PHP applications.

In PHP business logic is usually put right in action’s method or just behind it. Hence, every little piece of delaying and long-running code will be processed with a request. The problem is almost undetectable if a user sends an e-mail but with more complex actions it may take a little bit longer than preferred. [...] In this article I would like to make an attempt to present a solution to the very annoying everyday problem that probably many programmers came across in their organisations – deadlocks in databases caused by a vast number of requests in relatively short time. The main aim of this text is to introduce RabbitMQ, which I value as a very functional and practical message broker, to help you solve the queuing problems and decrease the amount of work you would otherwise have to spend on it.

He talks about why message brokers are even needed and how to pick the right one for your project. Then he gets into the "in practice" part of the article, showing the use of RabbitMQ through PHP to save various data to a database when a user is presented with an advertisement. He shows how to create both the producer and consumer objects, making interaction with the queue simpler. His examples are all using the php-amqplib by Alvaro Videla.

Lorenzo Alberton has a new post with an update about a library he's been working on to interface with Apache's Kafka system, "a persistent, distributed, high-throughput publish-subscribe messaging system".

Over a year ago I sort of reverse-engineered the protocol, and published a first rudimental library to produce and consume messages with version 0.05. Since then, the Kafka project has evolved a lot, moving from the LinkedIN repositories to the Apache Incubator, gaining traction, committers, features. The protocol has changed slightly too, so the old library doesn't work anymore with the new version (0.6+).

The library has gotten lots of new features in this update including gzip compression support, custom exception handling and better connection handling. He includes some sample code in the post showing how to create both the Producer and Consumer for the messages (and one for working with Zookeeper).

Lorna Mitchell has posted the latest in her look at OAuth in PHP to her blog today, an introduction to access tokens - generating and handling them in your application.

I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I thought I'd share my experience in this series of articles. [...] This entry follows on from the ones about the initial requirements, how to how to handle request tokens, and authenticating users.

In this latest post, she talks about the three different types of tokens - consumer, request and verififier - and how to use them to locate a user in your app's users. Her code validates the request token and verifier against the database and, if successful, inserts the rest of the token information for the user.

During some of his work with the Yahoo! Search Boss API, Till Klampaeckel came across an issue with the OAuth connection causing an error of "oauth_problem=consumer_key_rejected" with his Zend Framework-based application.

The above process doesn't even take five minutes, but then I spent eight hours figuring out what oauth_problem=consumer_key_rejected means. Spent a couple hours googling, reading bug reports and even posted to the Yahoo! group associated with Search Boss. To cut to the chase: When you create a new project, it's not sufficient to just activate "Yahoo! Search Boss" (and provide billing details and so on).

His real issue was because of how Yahoo! apparently creates (or when they create) the OAuth connection information for you. He gives a two line example of how the Zend Framework can grab a OAuth token with Zend_Oauth. He goes on to talk about the OAuth implementation in PHP and how it's "pretty sucky" and that there's not much documentation around to help. He got things working, though, and included the sample code he used to make the connection - pulling the info from a an oauth.ini file, pushing the authentication parameters to the remote side, grabbing the headers and making the HTTP request with the OAuth information in place.

Lorna Mitchell has a quick post related to some of the OAuth work she's done on both sides, consumer and provider. This latest post relates to the OAuth pages and endpoints that are needed as a part of the authentication process.

This article uses the pecl_oauth extension and builds on Rasmus' OAuth Provider post. [...] OAuth has a little more baggage with it than just passing a username and password to an API.

She lists the five things you'll need for your service and talks a bit about the registration process and how the consumer key/consumer secret keys are generated. There's no strict definition on them, so her example uses a combination of sha1, mt_rand and substr to get the job done. She also includes a sample "consumers" table for your reference.

On the Ibuildings techPortal there's a new post with the latest episode in their DPCRadio series (as recorded at this past Dutch PHP Conference) - Melanie Rhianna Lewis' talk on web services and consumer devices.

A web service is an API provided by a site that allows a remote application to access data and use functionality without having to 'act like a web browser'. [...] The talk will describe how a web service targeted at consumer devices can be implemented. It will look at the different methods of calling remote functionality such as SOAP, XML-RPC, JSON and restful services. It will also consider the limitations of consumer devices, memory restrictions, communications bandwidth restrictions, and so on that have to be considered when designing a web service aimed at consumer devices. Finally it will have a brief look at how to make a service secure.

You can find the slides for the session here and you can either listen to the episode through the in-page player or buy downloading the mp3 directly.

Padraic Brady has posted about a new inclusion that Google has announced will be included in the authentication methods for their APIs - OAuth.

The Google Data API support comes with a few gotchas. Its documentation show a clear preference for using GET instead of POST, though the Google OAuth server does appear to natively support POST requests for everything with the exception that it has a small bug which interprets an empty POST request body as a sort of phantom empty parameter.

He notes that the library he's been working on (and submitted to both the Zend Framework and PEAR) it up to the 0.0.3 release including functionality marked as beta for the Consumer portion.

Padraic Brady has an announcement posted to his blog today - his OpenID PEAR has officially been proposed to the PEAR group for consideration.

Yes, my OpenID 2.0 PHP5 Consumer has finally been proposed to PEAR. This brings the OpenID fanaticism on PEAR to four packages: OpenID_Consumer, Services_Yadis, Crypt_HMAC2, Crypt_DiffieHellman.

He'll be working to get the code "further up to par" including Nonce validation, more consistent error reporting and other operation modes (like check_immediate). He's also included a screencast in the post for those not familiar with OpenID to get their first dose.

Padraic Brady has an announcement posted to his blog today - his OpenID PEAR has officially been proposed to the PEAR group for consideration.

Yes, my OpenID 2.0 PHP5 Consumer has finally been proposed to PEAR. This brings the OpenID fanaticism on PEAR to four packages: OpenID_Consumer, Services_Yadis, Crypt_HMAC2, Crypt_DiffieHellman.

He'll be working to get the code "further up to par" including Nonce validation, more consistent error reporting and other operation modes (like check_immediate). He's also included a screencast in the post for those not familiar with OpenID to get their first dose.

Pádraic Brady notes in a new post today that his Services_Yadis package has been official proposed to the PEAR group:

This provides a PHP5 implementation of the Yadis Specification 1.0 a requirement of the OpenID Authentication 2.0 Specification. There are way too many specifications out there! The proposal is a reflection of February's "Zend_Service_Yadis" proposal to the Zend Framework. The main differences (beside the PEARification) were fixing the main bugs the ZF sample code had.

He also mentions his next proposal - to create an OpenID Consumer package.