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).

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.

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.

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.

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.

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.

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.

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.