It's been 2 weeks since the striping of EXIF data was put into place on the willow site. Last friday a redsign up uploaded and as part of this update I added the EXIF stripping to all the images on the site.

The following table shows how these changes have effected the size of downloads:

Week / Action	Bytes Transfered	Sessions	Bytes / Session
Week 1 - no image changes	2.50 GB	6,969.00	376.45 KB
Week 2 - striping EXIF data from thumbnails	1.81 GB	7,459.00	254.95 KB
Week 3 - striping EXIF data from all site images (minor design changes)	992.98 MB	8,459.00	120.20 KB

As the number of sessions has increased over the period I've used the Bytes/ Session to calculate that stripping the EXIF data from all images has resulted in a saving of approximately 30% (this figure is likely to be effected by the new lighter site design).

These changes have resulted in the site loading much quicker, especially the collection pages that contain a lot of thumbnails.

Those looking for others reason to strip EXIF data should read about this "incident", that resulted in this advisory.

Due to the as yet unfixed IE6 crashes I downgraded Xinha back to the previous snapshot R491. The actual revision is rather arbitrary but I know it did work ;)

There are lots of solutions out there when it comes to graphing data with PHP, mostly surrounding the GD graphics library that's included with most of the recent PHP distributions. Included in this list is the PEAR package Image_Graph, and PHPBuilder.com has created this introduction to help get you started with it.

This article looks at PEAR's Image_Graph package, which is released under the Lesser GPL. It's a package that has very little documentation, but which deserves more recognition. It's helpful to have used PEAR before, but if this is the first PEAR package you'll use, you'll probably cope just fine.

Formerly a SourceForge package known as GraPHPite, it merged with and took the name of an older PEAR Image_Graph package. The graphs, charts and plots produced by Image_Graph are highly customizable, and can be any of area, band, bar, box and whisker, candlestick, impulse, map, line, pie, radar, scatter, smoothed line and step.

There's a brief installation section to get things all set up, followed by a simple bar chart example that serves as a base for the rest of the code. They enhance it with colors (manually and via arrays), changing the font settings, changing out the type of graph rendered, and adding a heading to better define the graph's contents.

DevShed continues their "Managing the State of Applications with PHP Sessions" with this new tutorial, part two looking at the more advanced features that PHP has to offer to developers working with sessions.

This is part two of the series "Maintaining the state of applications with PHP sessions." In three parts, this series ranges from the basics of session management in PHP, such as creating, registering session data, and destroying sessions, to exploring advanced concepts, like working with different session storage modules and creating custom session handling objects.

In this article I'll take a look at them, in order to demonstrate with several code samples how to use them and how to take advantage of their many capabilities. Hopefully, when you finish reading this article, you should have a decent understanding of how to include advanced session handling routines within your own PHP-driven applications.

They start with the introduction to the session_set_save_handler function, making it simple to adjust how your script deals with sessions. This sets the stage for the next step in the tutorial - the creation of a MySQL handling system to store the visitor's session data. They wrap it all up with the code for the MySQL functions you'll need to get it all working, including handlers for saving, updating, and removing the session data that's in place.

php|architect has announced their Call for Papers for their next conference of the year - the grouping of php|works and web|works - targeting PHP and database developers looking for the best info they can get on a wide range of topics.

The theme of this year's conferences is "Lighter. Faster. More Powerful." Our goal is to highlight the ability of languages like PHP and database systems both open-source and commercial to help in the creation of nimble web applications that are modular and can be extended with ease.

As always, we are looking for very pragmatic talks that can offer the attendees information and knowledge that is likely to directly impact their day-to-day programming work. Naturally, this doesnt mean that your talks should be devoid of theoretical information-but, rather, that it should introduce the theory starting from a practical topic.

The deadline to submit your talk idea is June 5th, 2006 (which will be strictly enforced this year). The talks for the conference, when presented, will be "tagged" with relevant keywords to help developers narrow down the talks they're looking for instead of the standard "tracks".

To submit your talk idea, send off an email to proposals at phparch dot com and include all of the information mentioned here.

Chris Shiflett has posted his brief recap of his experience at the php|tek conference this year, including links to two helpful references - the page of slides provided by php|architect and a Cluesheet of tons of info from the conference.

There's also a comment made about the Call for Papers for php|architect's next conference later in the year.

On his Oracle blog today, Christopher Jones has posted a simple howto on getting the feedback the PHP Oracle functions throw when they error, only faster.

When a connection fails, you want to know about it as soon as possible. With Oracle Net there are many ways to configure connection and authentication. For example a connection:

$c = oci_connect("hr", "hr", "abc");

could be evaluated by Oracle 10g as using the Easy Connect syntax to machine "abc" (using the default port and database service) or using a net alias "abc" configured in a tnsnames.ora file.

He includes some settings to add to the sqlnet.ora file to help speed thing along - setting the directory path to enable a different authentication syntax and changing a setting to restrict the types of connect methods the client can try.

To show how it all works together, he gives an example of the tnsnames.ora, sqlnet.ora, environment variables, and the commands he ran to test it all out.

Scott Johnson has posted the promised podcast version of his talk given at the php|tek conference.

Thanks to Ashish for pushing me to get this up. This is a "re-podcast" (i.e. I re-recorded it while giving it to my cats; they didn't have any questions and seemed bored) since it was faster to re-podcast it than it was to edit it. Enjoy! Bear in mind that its highly nerdy and really intended for php geeks. But if you're interested in Internet scalability I suspect it will be interesting. Or if you're curious how we're building Ookles then its interesting (I hope). In it I also talk about the realities of MySQL Replication in large databases or as I term it "Replication Hell".

The file can be directly downloaded from his site as an mp3. The slides for the presentation can be found here

This week's newsletter contains news about the release of eZ publish
3.8, a beta release of our new template component and a few changes
here on eZ.no regarding documentation and specifications.

(Note: I might be unbiased as I'm one of the authors of the DBGp protocol.)

(Note: As the PHP IDE project seem to have swapped the meanings of client and server in their specification I will use the terms "debugging engine" and "IDE" in this overview)

Since a few days Zend has published their debugging protocol that they're going to implement for their Eclipse PHP IDE. This protocol is apparently a derivate of the protocol that they now use for their Zend Studio. Lukas already pointed out in his opinion open source should work in such a way that the best technical solution should be used, but the Eclipse project seems to work a bit different. In order to have a small view on what the "better" debugging protocol is I made a small comparison between the protocol that Zend published and DBGp that is used in Komodo and a number of other commercial, free and open source IDEs.

Protocol Communication

The PHP IDE protocol is binary while DBGp is an ASCII/XML based format.

A binary protocol uses less data over the wire and will therefore be faster to transport data with. However a binary protocol is also less flexible as all data types need to be defined exactly and the protocol specifications are required to be very rigid. An ASCII/XML based protocol uses more bandwidth, but it is more flexible as the format doesn't have to be so rigid. It is also much easier to debug by just looking at what goes over the wire.

Session Initialization

The PHP IDE protocol allows you select a host and port to which the debug engine should connect to the IDE through an HTTP parameter in the request to the webserver. DBGp does not have such mechanism.

On first sight it seems like a good idea to have the visitor of the web site to select which host and port to connect to as this makes things more flexible. However you should realize that not only the person who is debugging the application and set the host and port, but also everybody else who is visiting the site. Unless the debugging engine has configuration options to only allow a certain set of hosts this makes it easy for an attacker to manipulate an application. DBGp instead has the facility for Proxy Servers that allow you to have multiple people debugging applications on the same development server.

Transporting Variables

The PHP IDE protocol uses serialized data to transfer variables from the debugging engine to the IDE. (It does not define what kind of serialization is used, so I have to assume it's the same as the output of PHP's serialize() call). DBGp uses an XML format.

Of course serialized PHP data uses less data and an XML format to describe a variable takes more space. But PHP's serialized data is a format that is only specific for PHP and will not match correctly to other languages. DBGp's XML format is language agnostic and allows the definition of a typemap to see which language's native type maps to a DBGp data type.

The PHP IDE protocol allows you to select the maximum depth of variable contents to return when you request a variable, DBGp has something similar by means of setting options for a debugging connection. Besides a maximum depth DBGp also provides functionality for limiting the amount of elements that is returned in one array, and how much of the content of a variable is returned. This was added so that one array with 10.000 elements containing a 500 byte string can not clog down the connection between debugging engine and IDE.

Breakpoint Support

The PHP IDE protocol only supports either conditional breakpoints with a condition, or static breakpoints on a file/line number combination. The DBGp protocol supports breakpoints on exceptions, function entry, function return and watches as well. The DBGp protocol also facilitates that certain breakpoints should only be used when they're reached after or before a certain hit-count.

Output Capturing

The PHP IDE debugger protocol only supports "PHP Script Output", DBGp supports both stdout and stderr capturing in two types of streams.

Conclusion

The proposed protocol for the PHP IDE seems to be less powerful than the DBGp protocol. I wonder then also whether people on the Zend team actually had a look at the DBGp protocol. There were plenty of opportunies where we suggest that there is some discussion about the protocol but there was never any answer to this. In case you're interested in the DBGp protocol and want to discuss things with it, or if you want some help by adapting DBGp to use in an IDE that you are developing feel free to contact us at the Xdebug general mailinglist.