A pretty cool project in PHP - Memproxy is a caching proxy "server" that uses memcached for storing the cache. This project uses PHP scripts to handle caching using memcache.

The server uses memcached to store the information and automatically manages things like TTL, custom headers and is "application agnostic" all wrapped up in a small codebase with minimal dependencies.

Brian Moon has announced the release of the latest version of his memproxy tool that uses memcache to create a "server" to save the proxy information.

I put server in quotes because it is really just a PHP script that handles the caching and talking to the application servers. Apache and other HTTP servers already do a good job talking HTTP to a vast myriad of clients. I did not see any reason to reinvent the wheel.

Features of this new version include a TTL for the cached data, minimal dependencies for the application to use and a small code base consisting of two files. It also handles HTTP 1.1 requests, is transparent and applows pages to dynamically be specifically added and removed from the cache.

You can download this latest version from the project's page on the Google Code website.

Mike Naberezny has a new post today about one of the easiest ways he's found to "wrap up" those functions in your code that make the unit testing for your application break when you run it:

One of the problems that hampers the testability of PHP code is the coupling created by accessing all of the PHP global functions. This happens often because a large number of useful extensions are accessed only through global functions.

He gives the example of an LDAP connect script that, because it requires an external LDAP server to connect to and return a response from, would break the tests. His way around the problem is to use an extension versus just calling the object itself (code included) through a ExtensionProxy. Then, it's a simple matter of calling the proxy object with the type parameter for the function to be called and evaluating the response of the proxy instead of the actual call.

Brian Nelson has posted a follow-up to his previous article on creating a reverse proxy with PHP5, this time expanding on the functionality of it and reworking some to increase performance.

It's gotten a bit more complex; The proxy handler didn't pass all the client headers to the proxy server. This caused problems with having the wrong client type, no Etag caching, cookie passing, etc. Here's the current rev, which solves a lot of these issues.

The complete code for the proxy class included in the post and a note was added that there's now a Google Code project that's been created for it (svn repository).

Brian Nelson submitted a link to a new class he's developed to fill a hole he hand and didn't see anything that would easily fill it - having a reverse proxy in PHP5.

So I have been working on a little class to run a reverse proxy from PHP using cURL. I have extended this class for my own purposes (single-sign-on) to handle some special request parameters, but here it is. It has some warts, but it's a good starting point. I would appreciate any pointers anyone has to offer.

His code uses the cURL functionality to set up a handler to push the requests through. Also included are an htaccess file and a two-line PHP example of how to use it to request a public site.

From the Web Development Blog, there's a quick tutorial posted about using the PHProxy package and ip2nation tool to save you some money on your bandwidth bills each month.

If your website becomes a little busy the websites bandwidth becomes very valuable. If your visitors using too much bandwidth and the conversions from your website are very low or just moderate, it's possible that you get broke with also a good internet website project.

Their solution uses the PHProxy functionality and the IP address information (database dump) from ip2nation to create targeted user content. They include the setup for the proxy as well as some code that will need to be inserted to use the ip2nation data. Last but not least, there's also the code to insert into the page and make the magic happen.

In a new post today, Mike Naberezny talks about some updates that have been made to the XML-RPC client included with the Zend Framework, spotlighting three items in particular.

A few weeks ago, I rewrote the Zend XML-RPC client as part of a customer project at Maintainable. After fixing a fair number of bugs and writing a test suite, I made some enhancements and usability improvements. You can learn more about the new XML-RPC client from its documentation.

The three new updates to the package deal with:

• Calling remote methods (a new call() method)
• Server proxy objects have been added
• Faults are thrown as PHP exceptions

DevShed is wrapping up their "Building Proxy Classes with PHP5" series today with this last tutorial about working with directory iterators and proxy classes.

Since in the first part of the series I showed you how to create a proxy class for processing simple XML strings, in this installment I'm going to teach you how to create a proxy object that can be used in conjunction with the "DirectoryIterator" class that comes with PHP 5.

They start with the definition of a proxy class, the base to start from, and improve its functionality through additional methods like getSize, getPath, and getTimeStamps (using the iterators). The complete the development by pulling the parts together and creating a final example that loops through a given path and displays various info about the directory/files inside (size, names, timestamp, etc).

DevShed starts off a new two-part series today with this first look at building proxy classes with PHP 5.

In short, in the proxy pattern, one object is created by another only when the functionality of the first one is required. In this two-part series, I'm going to walk you through the key points of how to use this pattern with PHP 5, as well as how to apply it in different real-world situations.

They start with the creation of an expandable XML processor class that can be enhanced when additional functionality is needed. They use this class as a proxy for the requests and create a separate class (a normal XMLProcessor class) to perform the actual requests for the information - grabbing information from the loaded XML document.

Lukas Smith has a quick post today about some of the tension that's come up between to PEAR error handling packages and something he's created to try to help calm things down.

Well there is a lot of back and forth about if PEAR should mandate PEAR_Error or PEAR_Exceptions or neither for new packages. This also relates to the question of PHP5 E_STRICT compliance which PEAR_Error obviously is not.

His quick fix for the problem? Two proxy classes that would make switching between either of the two error handling classes as simple as changing out which proxy you're using.