Since writing this article I have been working on FirePHP 1.0 and a new client tool to achieve the kinds of things I describe below much more easily. The new tool is called FirePHP Companion and aimed at streamlining the PHP development workflow. There is still a lot of work left to do, but you can already take a look at how the demo provided here can be implemented easily with FirePHP Companion.

My purpose in this column is to introduce you to FirePHP, the problem it solves, and how it is intended to work within your application for maximum benefit. I will present some useful high-level knowledge to make it easier for you to integrate FirePHP into your application.

This is not a step-by-step tutorial. I have made a complete demo available for download, along with some useful libraries illustrating all the concepts covered here. I want to emphasize that the demo is only one possible implementation. There are many other possibilities.

The Problem

Building AJAX applications brings some new challenges to PHP developers. Apart from the fact that you need to learn JavaScript, which is probably a good idea anyway, you need to figure out a way to debug your AJAX requests. There are primarily two ways to do that.

The more involved option is to use an IDE with an integrated debugger. While this may be the most powerful approach, it typically is also the most complex, expensive, time-consuming and cumbersome, especially when it comes to triggering the debugger for a specific request.

The second option is to simply print out debug information using var_dump() or print_r(). This approach requires you to examine the response of the request in Firebug, or to run it in its own browser tab. It also breaks your JavaScript AJAX code, because the response is no longer a valid XML or JSON structure.

The ideal solution would be something that is easy to set up and use; something that will allow you to view any PHP variable without breaking the response content, so that your JavaScript code can continue to execute as intended. This is precisely what FirePHP is designed to do — this, and more.

The FirePHP Solution

FirePHP solves the problem of AJAX debugging by sending debug information along with the response. To avoid breaking the response content, the debug information is placed into special HTTP response headers. This works for all types of requests, not just AJAX requests, which means you can even debug requests for images that are dynamically generated by a PHP script. You can use FirePHP in your development environment, or use it to track down bugs that only appear on your production site.

The FirePHP system requires two components to work. The first of these comes in the form of a Firefox Extension that extends Firebug. It reads the special response headers and presents the debug data in an intelligent way within Firebug. The second component is a PHP server library that provides the necessary functionality to encode PHP variables and sends them in the response headers.

Detailed information regarding how to install the FirePHP components and how to get started with their basic functionality is available on the FirePHP website, to which you will be directed when you install the FirePHP Firefox extension.

Persistent and Controllable

There is significant benefit in leaving debugging code in your application and being able to easily enable the desired debug output as and when required. This is primarily useful when working with object oriented code, where common components are re-used in different areas of the application and may become part of several iterations of debugging when tied into different end-user functionality. One such component, for example, would be a caching object.

When debugging such an object, you would typically want to be able to view information about the cache such as filenames, whether the data was created or fetched from the cache, and when the cache entry will expire. Going one step further, during debugging, you would want to be able to control the cache lifetime, force cache expiry, and conduct some analysis on the amount of resources used and time taken to create the data that is being cached.

Having debugging code in your application and being able to trigger it in a secure way may also come in extremely handy when something that worked fine during development is not working quite as it should in your production environment. In such a case, you’ll want to be able to easily view specific information about your backend without making it available to all.

Design Philosophy

FirePHP is designed to be non-intrusive so that you can decide how and where to use it within your application. It essentially provides a mechanism to send logging events to the Firebug Console without interfering with your application. There is no built-in security to safeguard the data you send, which means that you are in charge of security and in charge of deciding what to send, when to send it and to whom.

All data is sent in clear text in the response headers, unless the request was made via HTTPS in which case the entire response —including the headers— will be encrypted.

Although the chosen design may put the burden of security on you, it gives you complete freedom over how to use FirePHP within your application. The remainder of this discussion will focus on the best practices of how to integrate FirePHP into your application to implement some powerful debugging functionality while ensuring security and maintaining flexibility. A basic understanding of the FirePHP API will help, but is not essential.

Enabling FirePHP

As soon as you include the FirePHP server library in your application, FirePHP is enabled and you can log to Firebug:

FB::log('This is a log message');

This makes it very easy to get started, and provides a great alternative to using var_dump() or print_r() during development or ad-hock debugging. When you use FirePHP in this way, you would typically only log variables during development and remove all your logging statements before uploading your code to a production server.

If there are logging statements you want to keep in your code, to save you time in future, you can manually disable FirePHP with

FB::setEnabled(false);

before uploading your code. This will stop your logging messages from being sent. However, if you rely on this method, apart from the fact that it is cumbersome, there will likely come a time when you forget to disable it before uploading your code. In that case anyone who has FirePHP installed will be able to see your logging messages, which may or may not be a problem depending on the data you are logging. You probably don’t want that to happen.

A better approach would be to use a configuration setting to determine whether FirePHP should be enabled. Chances are your application already uses a configuration file you can use. Adhering to good security principles, you will want to disable FirePHP by default and only enable it if a setting is found that specifically overrides the default. The code could look something like this:

$settings = @parse_ini_file('settings.ini');
 
if ($settings['FirePHP'] == 'Enabled') {
  FB::setEnabled(true);
} else {
  FB::setEnabled(false);
}

When this is set up, all you will need to do is use different values in your configuration files in your development and production environments, and you will never need to worry about FirePHP being enabled by accident again.

If you want to enable FirePHP for specific users no matter which environment the application is running in, you can tie the above code into your user privilege or session system.

Selective Logging

To realize selective logging by allowing a user —or more specifically, a developer— to turn on and off specific groups of logging messages, requires a bit more work. Such a system typically consists of an administration interface allowing the developer to tweak logging options, and a wrapper object for FirePHP that is used in the application to intercept logging messages and only send them if requested.

The options defined in the administration interface will need to be accessible to the wrapper in the application. This can be done on the back-end via a shared session or cached file, or on the front-end via cookies. The approach you choose depends on how your application is structured and whether the administration system runs on the same domain as your application. The cookie approach is probably the easiest to set up, allowing the administration interface to be coded entirely in JavaScript.

Let’s say you implement the administration interface for the debugging options in JavaScript. The user interface could be tailored to look consistent with the rest of your administration system, and could be used to set, say, a cookie named Debug to a value of DisableCache when that option is selected.

Your wrapper on the application side would look something like this:

class Debug
{
  public static function getOption($name)
  {
    $options = @explode('|', $_COOKIE['Debug']);
    return(is_array($options) &&
    in_array($name, $options)) ? true : false;
  }
}

You can then ask the wrapper whether a specific option is enabled, and act accordingly:

if (Debug::getOption('DisableCache')) {
  // code to disable cache
  FB::info('Cache has been disabled!');
} else {
  // default code
}

Make sure that the debugging options always override default behaviour, and that the application will continue to function if no debug cookie or option is defined. You should always return FALSE for the debug options if the user is not authorized to use them.

I encourage you to look at the source code of the demo mentioned earlier, which illustrates the cookie and JavaScript-based administration interface approach. Rip out the code you like and make it your own.

An Eye to the Future

I have been toying around with development and debugging systems for a long time. FirePHP is my first public, stable and practical implementation to a problem area I find fascinating.

I have never been a real fan of interactive debuggers, primarily because they don’t support my write a little code, run it, write some more, re-run it development approach, which seems to be quite common when building Web applications with scripting languages. As FirePHP is coming into its own and I can observe how others use it, I see tremendous opportunity in evolving this type of development approach further. I’m not talking here about just the debugging aspect, but rather a system that can easily be tied into any application to provide the developer with a powerful user interface that can visualize the internals of an application. One that allows the developer to configure components for different environments and stages of the development cycle.

It would be much easier for a new developer to learn their way around a codebase if they could see the order of execution visually on one page without having to step through the code. It would be trivial to provide mock data to application objects where certain services or classes are not yet complete by defining the data in your browser.

I encourage you to look both at FirePHP and at the big picture it points to. FirePHP represents a humble beginning to a problem area that is desperate for attention, and provides an enormous opportunity to make all our lives easier.

UPDATE: Oct 20, 2010

Since writing this article I have been working on FirePHP 1.0 and a new client tool to achieve what I described above. There is still a lot of work left to do, but you can already take a look at how the demo provided here can be implemented much more easily with FirePHP Companion.

What sealed the deal for me was the result I got when I applied a 10 minute inspect-search-edit-refresh technique I use when learning the ropes of a new architecture and implementation. Lets call this technique “dive and swim”.

Before I get into what got me excited I am going to give you an insight into how I approached this new candy store called Bespin.

Extra! Extra! Read all about it!

Before you dive into new code you are well advised to get your bearings first. By bearings I mean valuable facts about the application that give you a rough overview about what to expect. This is important because it reduces the likelyhood of running into dead ends when you investigate the code and can save you a lot of time.

Bearings for Bespin are things like:

• It’s all open source
• The client is written in JavaScript
• It has a client and server component
• It uses CANVAS to render it’s UI
• It has a grand vision

There are many sources you can use to get some important facts:

• Read the announcement
• Play with the demo
• Skim the documentation categories/headings
• Skim mailing list subjects (to determine aspects that excite people or common problem areas)
• Skim README files

The idea is to get a global picture of what to expect, not to actually study anything in detail unless something catches your interest of course. Now bearings are useless if you don’t know how to interpret them. That is where your experience and intuition come into play. The more you have the faster you can move to the point where you can skip a lot of these steps – because software development is an art, but also a science and with science comes true and tried techniques/concepts/standards that span all decent implementations.

Going back to the Bespin bearings from above, filtered through my experience I get:

• It’s all open source – You can download and play with the whole system, discuss it with others, search online for blog posts, read mailing lists etc…
• The client is written in JavaScript – The client can be extended and monkey patched easily and refreshed in the browser to see the changes.
• It has a client and server component - The server component is likely not implemented in JavaScript as server-side javascript is still too new to be used as the primary backend for a project that aims to gain a large audience fast. So the server is written in a different language than the client leading to the conclusion that some well-known protocol that is cross-language is likely used to link the two.
• It uses CANVAS to render it’s UI – see below
• It has a grand vision – The developers put a lot of thought into it (I should find well-structured code) as only a fool would set grand goals and publicly parade them without having the experience, insight, research, passion and backing to actually follow through.

While the bearings are objective and subjective facts your interpretations are assumptions you carry into the candy store and validate as you raid the shelves (read files).

The CANVAS Bearing

For me the most interesting bearing and reason for further investigation (other than the explosive welcome Bespin has received) was the fact that is uses the CANVAS HTML element to render it’s User Interface. Why is the whole CANVAS thing so interesting? Because CANVAS has been lurking in the shadows of HTML+CSS for a while and until now never showed itself in this way; maybe for games; but not for a component-based UI with user interaction (at least to the best of my knowledge).

Why is this whole CANVAS UI implementation so interesting to me? About 10 years ago I wrote something similar using Java. At the time SWING just came out, was not known to me, not practical to use yet or did not do what I needed at the time (I cannot remember) so I ended up writing my own UI toolkit.

I created classes for different UI components and layout managers that rendered pixels into a coordinate system that was displayed to the user as an image. Mouse events on the image were captured and dispatched to the appropriate UI component that was rendered at the given coordinates. The whole UI layout and components were defined using an XML document and each component had a data provider class that buffered data access to underlying data sources. Components were linked and business logic added via an event system using listeners and dispatchers.

From what I remember I spent a lot of time on this. At least 6 months of development while studying at university and the result looked and worked pretty nice. Here is a few screenshots I was able to dig up. Have not found the code yet.

When looking at Bespin I used my past experience in writing a similar UI toolkit as a map so I knew what to look for. I roughly knew what was needed to implement the Bespin UI functionality and had a shortlist of concepts in mind of how the whole app was put together.

Having such past experience gave me an unfair advantage in this case. It goes to show that any experimentation you do in your early years of development may potentially pay off in future.

Now I don’t want to promise something I cannot deliver on but I would not be surprised if I ended up putting some real time into hacking around with the CANVAS UI Toolkit in Bespin, pulling it out of Bespin and looking at how I can expand on it and incorporate it into some of my other projects.

(Inspect<->Search)-(Edit<->Refresh)

Once you found your bearings and formed your assumptions you are ready to dive into the code. When using the dive and swim technique you are best advised to use it on a working install of the app. It has to be working because you are going to make edits to the code and then refresh/restart the app to see what changed.

Inspect

Start by asking yourself a question. Something like: How can I make a simple change to the code that will change something in the UI?

Combine that with your asumptions and you get something like: Let’s look for the generic UI toolkit classes. You arrive at this action step because you know what is likely needed to render the UI and you know how it is likely implemented.

Browse the code tree in your IDE’s Project Explorer (I use Ecplise) and open files that based on their name and directory could have something to do with the UI toolkit. When you find something that looks like it is related look for variable, class, object member or function/method names that are likely part of a public API of the UI toolkit and used wherever the application defines it’s UI.

For instance I found the Scrollbar variable/class in /frontend/js/th/components.js

Search

Next you open a search dialog box that can search across all files in the project and input your Scrollbar keyword. The search result in Ecplise is nice because it shows you the files containing matches and the location of the files in the project directory structure. With every search you do you will get more familiar with the way the code is structured as the results show you where and how (once you inspect the result files and matches) the public API of different components is used within the app.

Doing this search & inspect on Bespin for example revealed to me that it looks like the Scrollbar defined as part of the UI toolkit is used for other UI toolkit components but not for the editor which seems to implement it’s own scrollbar.

When I was skimming /frontend/js/editor/editor.js I saw a variable that caught my attention as a potentical candidate I can edit to create a simple change in the UI (my original objective): this.GUTTER_WIDTH in Bespin.Editor.UI.

Edit

Make a small change in the code. When setting a variable to a new value, choose a value that you think will result in a noticable difference but one that you think still falls within the acceptable value range of the variable that may or may not be explicitly validated. You can also modify methods, add alert() calls or log to Firebug depending on what you are trying to figure out.

I changed the value of GUTTER_WIDTH from 54 to 34.

Refresh

The final step is to restart the application. Since Bespin is implemented using JavaScript this is really easy and requires only a refresh of the page. Look for the change you intended on making. If you can find it your quest was successful, if not you will have to trace the code a bit more to see what went wrong.

I was very happy when I saw the gutter shrink in size after a quick flicker of the UI (the refresh is fast which helps a lot in speeding up your edit<->refresh iterations). This humble result was enough to get me excited because after only investing 10 minutes I got a result I expected. Going into this I had an expectation of how easy it should be but nothing prepares you for how you feel when it actually is that simple, works and just feels right.

In Conclusion

There are many ways to go about learning the code of a new application. I shared with you a technique I have developed over the years that has served me well and got me results fast in short periods of time. It works particularly well with JavaScript and more generally scripting languages as you can search-edit-refresh the application in a matter of seconds.

If you are interested in Firefox extension development I highly recommend applying this technique to see how it works for you when learning from other people’s extensions because it seems to be particularly effective. I found that out while developing FirePHP where I needed to learn the Firebug code.

Remember that the dive and swim technique is an iterative process. You need to stay flexible and follow your intution and whatever catches your attention during the inspect<->search iterations.

Just as Mozilla enables massive innovation by making Firefox open on many levels, we hope to do the same with Bespin by developing an extensible framework for Open Web development. We’re particularly excited by the prospect of empowering Web developers to hack on the editor itself and make it their own.

I encourage you to check out this project. It’s in a very early stage of development, so don’t expect to switch IDE’s any time soon, but based on the amount of interest it has already generated the project is going to evolve quickly.

If you want to see what is being talked about in terms of features and opportunities take a look at the Bespin Think Tank. That is what I am calling the mailing list for now as it seems to be one massive flow of brainstorming rather than action oriented messages.

Exciting to me is that several other notable projects are already talking with the folks at Bespin to see how they can work together. One is the Firebug Working Group with the aim of integrating Firebug with Bespin, the other is the E4 Eclipse Project which is a community effort for building the next generation of the Eclipse Platform. There is already an experimental e4 Bespin server which was announced by Boris Bokowski and a cross-country in-person meeting has been setup between the projects to discuss further collaboration.

My Take on Bespin

I think the whole idea of an extensible framework for Open Web development is great. A major hurdle to IDE innovation is the barrier to entry experienced by developers wanting to add features to existing IDE’s. To add features to Eclipse for example you need to be a Java developer which limits the amount of people who would even consider writing plugins. If Eclipse plugins can be written in JavaScript using a powerful and intuitive plugin development environment Eclipse could experience the same kind of extension explosion as Firefox.

Since my last post about an AJAX-based Eclipse Project Explorer I have started communicating with the E4 project team. My interest is in building a plugin framework that enables developers to build and publish JavaScript-based UI Widgets using Firefox/Firebug and then be able to run them in any web page, browser extension and IDE staring with Eclipse.

The focus of my effort is not on just re-implementing existing IDE functionality in JavaScript but rather linking Eclipse Views such as the project explorer to the web so that data available locally may be augmented with data available from web services. Once you can build Eclipse Views using JavaScript and feed these with local and remote data I think we can speed-up innovation of IDE’s and link them much closer to the cloud where it makes sense.

FirePHP and Beyond

If you are using and like FirePHP you are going to love what I am working on as the next evolution of my concept of web-based developer tools. I’ll be posting more information on my blog in the coming months. I encourage you to subscribe if you want to see what I am up to and provide your feedback early-on.

• Icons for different file extensions
• Version information about the directories and files if connected to a version control system
• Context menus specific to each directory and file

This widely accepted approach to represent code files in a project has worked well in the past because projects and project components were typically:

• Written in one or several complementing programming languages
• Largely self-contained with required libraries imported into the project
• Mostly closed off to the outside and interacting with other applications through interfaces available only when the application is running in a development, testing or production environment
• Left for the developer to locate on the internet, download, import, maintain, test and publish

The traditional project explorer worked well for traditional web applications because it left application and file structure completely up to the developer. This was important because there were few frameworks available that combined HTML, CSS, JavaScript and PHP code into a cohesive architecture. The developer was able to structure code based on experience, trial and error and best practices where existent.

The downside of this approach to project structuring is that there is little standardization between projects making code sharing difficult and increasing the learning curve for new developers learning an existing application.

While code and component re-use and standardization across projects was and still is desirable the traditional project explorer offers little support to the developer in keeping things standardized. After all it only mirrors what was on the file system without any manipulation of the directory structure.

The need for a new kind of project explorer for web applications is primarily driven by forces such as:

• Increasing standardization in web technology library distribution and project integration
• Application deployment to standardized cloud environments
• Platform-as-a-service offerings
• Open source movement with many contributors to many project components

The AJAX-based Project Explorer

The purpose of the AJAX-based Project Explorer (APE) is to:

Liberate application architecture and lifecycle possibilities by lifting code organization from the file system.

For an APE the local (or remote) file system is no longer the source of data for the project explorer. Furthermore the APE does not dictate how a project’s directories and files are displayed allowing for an application-specific user interface. The interface would of course be an AJAX app that is fed from a server.

Thinking this through from a traditional web application development perspective makes little sense. Where would the AJAX app be hosted? How will the AJAX app know about the project files? Where do the project files reside?

The key to the APE is standardization and the use of a framework or a platform as a service. The framework would provide the AJAX app for the APE and the developer would write the application within the possibilities of the framework.

Advantages (Local Development)

The advantages to an APE are numerous and significant. Let’s say you want to develop a PHP application. You choose Zend Framework (ZF) as your framework because it provides ultimate flexibility and power and is supported by a large and active community.

ZF is a good choice because it imposes some standards on you including a well-debated recommended project structure that can be described via an XML definition file. The definition file can be used by Zend_Tool to make changes to your project.

ZF would provide an AJAX app for the APE (ZF-APE) that would be hosted on the same development server as your project code. The AJAX app would integrate with Zend_Tool to gain access to the project files in a standardised fashion via the XML project definition.

In it’s simplest form the ZF-APE would provide a traditional view into the project files using a file system based tree. Things start to get interesting when more meta information about code files, directory structure conventions, file contents, etc… is spliced into the ZF-APE. This information can be made available because the AJAX app is specific to the framework and the framework provides tools to reflect project meta data.

You could, for example offer:

• Filters on the file tree that would only display library files, controller files, view scripts or unit tests.
• Recognize components (as a collection of files following certain conventions) and displaying the components in more intuitive ways rather than a simple list of files.
• Different context menus for different files, directories and components allowing arbitrary execution of Zend_Tool features such as component creation, running of unit tests and packaging of project.
• A view that shows all controllers and actions in a tree that will launch the appropriate code file and position the cursor to the correct line when clicking on an action.
• Coding standard validation information for each file and component (using server-based or thrid party validation services)
• Unit test coverage information
• Integration with a debugger showing which file you are currently stepping through

The possibilities are endless. The point to note is that the APE will allow more intuitive project navigation and abstraction of standards away from files by focusing on logical entities instead. It enables simple means to acess a diverse set of files that may be spread all over the project codebase but belong together in a logical unit.

Advantages (Platform-as-a-Service)

Arguably the largest benefactor of the APE will be platform-as-a-service vendors. A service offering PHP, Ruby, Python, server-based JavaScript, some standard way to include common client-based JavaScript libraries, a database abstraction layer and content delivery network could provide an APE AJAX app that ties all these services into one coherent interface.

Rather than requiring the developer to use some online portal or vendor-specific IDE that is tied into their service (because project files are spread over several file systems in their internal system) the developer can acces the service via APE and a familiar IDE.

In this scenario the developer can write code, instantly preview the application on a development server provided by the vendor, publish the app to production servers and monitor it all without needing a local development environment. The vendor could even tie billing and account information into the APE to make the experience as seemless as possible.

Technical Requirements

Making APE a reality is actually a lot simpler than one may think. Let’s briefly examine what it will take:

• A new APE view for eclipse that loads any URL in an embedded browser (ideally Firefox)
• Several API’s to bridge between the loaded AJAX app (JavaScript) and eclipse (Java)
• A component for eclipse that communicates via the AJAX app with the project server allowing eclipse to mirror the logical project file system.

Important to note is that the project server provides a LOGICAL file system to eclipse. Eclipse editors and tools are based around files and directories. Changing this would be utterly impractical and is not necessary. So we need a way to mirror the actual distributed project files from the remote system via a unified logical tree to the local eclipse environment.

All project files would always be present locally and sent to the server when modified. This would allow existing eclipse tools such as search and many different project inspectors to continue to function.

One last important point to note is the directory and file structure will be less important to the developer over time. Absolute file locations in the project will become less important and relative location to a specific context (group of files) will become the focus. The actual mirrored directory structure will be optimized for eclipse tools and not for the purpose of having an easily comprehensible directory structure as is the case in traditional project explorers.

The code within files must not be complete in a traditional sense as the file is only a logical bucket. For example a file can contain code for only one specific controller action without all the plumbing code to wrap the action code. By itself the code would not run. However the project server knows where the code belongs in the project, what it needs to be wrapped with and how it needs to be organized relative to other actions.

Call to Action

If anyone out there is interested in exploring the APE concept by building the required view into eclipse and developing the necessary API’s and sync manager I would be very interested in building the first APE AJAX app to integrate with Zend Framework.

The release includes 27 bug fixes and feature enhancements. The scope of this release was primarily focused on improving the current feature set in terms of usability, reliability and support for logging complex objects. You can find the changelog here.

After installing the FirePHP 0.2 extension you will be directed to the Install page after your next Firefox restart. On this page you need to download the updated FirePHPCore library. Next you can visit the Learn page for information on how to get started with FirePHP. Finally refer to the Usage page as a reference for all supported features.

I want to thank everyone who has participated in the Community Forum and Issue Tracker to report, test and resolve issues. Your help has been invaluable to make this release possible.

Finally, I have a new Contribution page that includes a Donation button. If FirePHP saves you time I encourage you to donate what you believe is reasonable. It will allow me to spend more time maintaining FirePHP and make improvements that are suggested.

The 0.2 release includes the following improvements. See the Usage page for more information.

Enhanced object logging

FirePHP will now log and display non-static private and protected object members. If they are declared static they can be logged with PHP 5.3. The variable viewer will indicate the visibility with a little icon. Red is private, orange is protected and green is public. Grey means undeclared (you have assigned a value but not declared the variable in the class) and the square means it is static.

Logging complex objects containing cyclical references to many other objects is no longer a problem. By using options you can now specify the mximum depth to traverse objects and arrays. You can also exclude specific object members from being logged in order to remove infomation that is not required and will only slow down your debugging.

File and Line Information

By default you can see the source file name and line number where each message was triggered when you hover over the message in the Firebug Console.

Full UTF-8 and Latin-1 Support

FirePHP now supports UTF-8 and Latin-1 (ISO-8859-1) encoded files and strings. All other encodings should work as well as all data gets converted to UTF-8.

Enhanced Variable display in Console

The variable display in the Console has been completely overhauled. Different types of variables including objects and labels are now properly displayed, abbreviated and highlighted.

Other Improvements

• The Variable Viewer can be resized
• FirePHP will tell you when you need to upgrade your server library
• Built-in error and exception handlers
• Message grouping
• New object oriented API to access FirePHP via static methods
• Support for Firebug 1.3