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.

As mentioned by the php|architect website, the results are in for the Community Awards competition SourceForge was hosting for the year and two PHP-based projects made the list - phpBB and phpMyAdmin.

The Community Choice Awards are over! The SourceForge.net 2007 Community Choice Awards provided you an opportunity to recognize projects that stand taller than the rest. Everybody got to vote, and everybody's vote counted equally. The winning projects, each with superlative quality, productivity, and ingenuity, represent the cream of the crop on SourceForge.net.

phpBB made the cut in the "Best Project for Communications" category and phpMyAdmin won in the "Best Tool or Utility for SysAdmins". Congratulations to both projects on your achievement!

PHPBuilder.com has posted part two of their look at combining Ajax and PHP. They take things a step further than last time and look at the actual communication between the script and the server.

AJAX and PHP 5 both have powerful features for processing and using an XML document. XML is a method of formatting data often for communication purposes between different computer systems. In this article, we will show you how to access an XML document with AJAX!

They create a script that can load the XML information from a file and echo it back out to the waiting client script. They also include the other half - the client-side javascript that grabs the XML information, parses it, and pushed it into a javascript object for easy access.

New from Iain Dooley on the Working Software website today is his look at working with threading in PHP including forking and communication between the processes.

I recently wrote a little application that dumps a file across a forwarded port. [...] So when I first wrote it, I didn't know what I was doing and had never written socket code before, so it was a big procedural mess. Naturally I was keen to separate out my socket class into it's own package but this presented a problem: the controlling process needed to check the status but how could I decouple the process that instantiated the socket class from the socket code itself

So, he set about working up his class, hitting a few barriers along the way:

• Copy On Write issues with how PHP handles the variable for the forked process
• Interprocess Communication using Sockets using the socket_create_pair function
• a "Curious Interlude" about why you can share sockets between two processes

There's a example of it in action - a setup with a child process that's all set to count up and respond back with the current number to the managing script.

Continuing on from a previous post on multi-threading in PHP, Brian Bosh is back with something a bit more developed that will allow for communication between the threads as well.

Earlier this week, I suggested PHP could be multithreaded. The sample I provided was very simple and at least one reader quickly wondered how to communicate with threads. If you haven't already, take a look at part 1 to get some basic information about threads in PHP.

It took a bit longer to get that part working that simple threads, but as of now, I have a functional prototype of an HVAC thread.

The post is broken up into five different files to make things work:

• an overall class for the main functionality (their example of running the heater or AC)
• a class to create and set up a thread
• a "thready utility" class to handle the response from a thread
• a thread library to handle creation/interaction/etc
• the example file of the system in use

CakePHP users out there looking to squeeze just a bit more out of their plugins might want to check out this new post over on Felix Geisendörfer's blog today. He shows how he's worked around two issues that have bothered him with the current framework setup - inter-plugin communication and filter callbacks.

He starts off by looking at the filter callbacks, looking to make "drag and drop-able" plugins for his setup. He notes that, right now, you'd have to call a plugin to perfom an action, making for a good bit of load depending on the application structure. It also means that you have to change the Controller to add a new plugin ("...which doesn't seem like a very RAD approach to me").

So in order to streamline such plugin callbacks, I created a function inside SpliceIt!, that allows plugins to hook into any AppController event, such as beforeFilter, afterFilter, beforeRender, etc. in order to make their own changes to the controller. So a Themes plugin can easily change the Controller::view and a Statistics plugin can make calls to a Model.

He gives the code for the function as well as an example of how to use it in your app.

Moving on, he looks at his next issue to overcome - inter-plugin communication:

Generally spoken Controller::requestAction() isn't a bad way to exchange data between controllers. It's a clean interface and you don't have to plan in advance what data should be exchangeable and what data should not. However, there are a couple problems with it.

His solution involves the creation of an entirely seperate ApiController pattern. Of course, he provides examples, specifically related to his SpliceIt! application.