Adam Peterson has posted an interesting idea for those out there running an internal staging server they want to constantly keep up to date with the main line of code (without manual intervention) - a git pull web frontend combined with git post-receive hooks.

This [move from svn to git] left a bit of a gap in my process where I could no longer test on a remote server without updating it manually by S/FTP or opening terminal and manually calling a git pull. Open terminal and manually git pull it did break up the work flow a bit so using the Dingo framework I created a very simple Git helper and gave it its own URL something like git/pull.

He added a post-receive hook to his git server that calls this "git/pull" URL on the staging server and updates the code on the server. This provides an easy asynchronous way to update things on another server. Note, though, that this should never be done on a publicly accessible server - it's a pretty large security hole (or at the very least made secure somehow). He used Dingo to create his interface, but something like the Slim micro-framework could have worked just as well. You can view his code on github.

In a new post to the ThinkPHP blog today there's a look at combining Comet with PHP to make a simple method for the client to talk back to the server outside the usual methods.

If a couple of users have opened the application there are already some hundred or thousand requests per second. The outcome of this is a big load for your server and a highly increased traffic - your server will in a senseless way be overloaded. In conclusion, our problem is the enormous amount of polling without knowing whether the server really wants to send a new push. Let's turn the initial situation around. And we get the solution to our problem: Comet.

With Coment, the model changes and the request is "cached" on the server-side automatically in a single Comet instance. Coordinate this with another recommendation of theirs, a PHP socket server, and you can do some pretty interesting things.

The IBM developerWorks site has posted part four of their series looking at the Zend Framework. This latest article focuses on the Zend_HTTP_Client package.

Part 3 explains how to use the Zend Framework to construct our online feed reader, Chomp, by creating an interface to subscribe to and read feeds, and to save feed entries into the database. Now you will learn how to use the Zend Framework to incorporate Web sites that do not support RSS feeds into the online feed-reader interface.

They work their way through an example of pulling in content from a remote site (one that's feedless). This is an enhancement to the "Chomp" application they've been developing all along, so if you need to catch up, here's the previous parts - Part 1, Part 2, Part 3.

They update the indexController, deleteEntryAction, and the saveEntryAction methods to handle this new incoming data and make the needed changes to the views to handle the new output. Finally, they demonstrate how to save the entries pulled in through the Zend_HTTP_Client component.