Greetings

[Thomas Endres]

Hello there,

My name is Thomas Endres. I have created the FireP4j (Java/Groovy)
library for FirePHP.
You can download my work at firejavalib.wordpress.com (there is a link
to my GitHub page).

I'd like create a Java/Groovy library for the FireConsole project in a
similar way that I did with FirePHP.

Best wishes,
Thomas

[Christoph Dorn]

Hi Thomas,

Thanks for your interest in FireConsole.

I have taken a good look at your project at: http://github.com/theone1984/FireP4j

You have done an excellent job on the data collection side and general
design of the Java API. Getting the library to work with FireConsole
will primarily be an exercise of porting a new protocol implementation
and refactoring the library in a few specific ways. Since FireConsole
is going to replace the FirePHP extension (the FirePHP server library
will be the sole future focus of the FirePHP project) you will only
have to maintain one library going forward and it will work with all
clients that implement the wildfire protocol and insight data
collection and redering system.

I'll begin with an overview of the projects involved and provide
enough detail to get you started. The Java port would be the third
implementation (I already have PHP and partial CommonJS JavaScript
implementations and there is interest in a Ruby port).

Recap: After I wrote the original FirePHP in 2007 and based on the
feedback and interest since then it has become obvious to me that the
logging-based debugging/development approach to a visual client is a
great alternative to more traditional techniques of print statements,
server logs and interactive (step-by-step) debugging. I have taken an
interest in bringing a new debugging approach to dynamic/scripted
languages and to accomplish this have devised a set of MIT licensed
projects and protocols that are flexible enough to work across
programming languages to shuttle data to CommonJS [1] based clients. I
am evolving the CommonJS Client infrastructure as part of the FirePHP
Companion [2] and FireConsole projects and will be opening up and
documenting this codebase for integration into any client/IDE that
supports a CommonJS module runtime. I wrote about one area of
application for what I am building here [3].

The plumbing projects: The wildfire [4] project implements the
mentioned communication system and the insight project [5] collects
data on the server, packs it for transport and displays it on the
client. Both these projects follow a generic design, propose an API to
be consistently implemented across languages and at its most
fundamental level provide a mechanism to render data structures via
JavaScript renderers [6] on a remote client.

Wildfire provides mechanisms to send data along existing application
communication channels without interfering with the functioning of the
application (i.e. out of band). The most obvious example is sending
debug data in the HTTP response headers as the traditional FirePHP
utilizes. I have expanded this to support client to server
communication (via request headers) and have prototypes that get
wildfire data form stderr command output. The idea is to devise a
communication systems able to channel out of band data through the
physical and software infrastructure of applications by providing
libraries/hooks for strategic points in a system. One such example
would be a wrapper around PHP's remote URL fetching (used during web
services requests for example) to inject and pull out HTTP headers and
relay these to the client out of the box.

The API for wildfire is proposed to look like this [7] (JS
implementation is here [8]):

$channel = new Wildfire_MessageTest__Wildfire_Channel_HttpHeader();

$dispatcher = new Wildfire_Dispatcher();
$dispatcher->setChannel($channel);

$message = new Wildfire_Message();
$message->setData('Hello World');
$message->setMeta('{"line":10}');
$message->setProtocol('http://pinf.org/cadorn.org/wildfire/meta/
Protocol/Component/0.1');
$message->setSender('http://pinf.org/cadorn.org/wildfire/packages/lib-
php');
$message->setReceiver('http://pinf.org/cadorn.org/
fireconsole');

$dispatcher->dispatch($message);

$channel->flush();

Messages may be of arbitrary size, contain arbitrary ASCII data,
support JSON encoded meta data and specify a protocol, sender and
receiver. The protocol defines how message data is to be structured
and handled on a macro level and the sender and receiver are used to
channel the data to the appropriate target. You can read a bit more
about this here [9].

The ideal approach would be to provide a Java port of wildfire and
place it here:

http://github.com/cadorn/wildfire/tree/master/packages/lib-java

with an API that follows the essence of the PHP and JS
implementations.

The insight project is concerned with collecting data, generating
static JSON-encoded object graphs composed of generic primitives with
language-specific type hints, sending these to the client via wildfire
and rendering the object graphs via pluggable CommonJS modules in
various clients. While each client (FireConsole, FirePHP Companion,
Webkit WebInspector[9]) may have a differently structured UI and
different approaches to select and filter debugging data insight
attempts to generalize an API that works across different client
implementations.

The initial Insight API as implemented in FirePHP is documented here
[10]. The implementation is here [11].

I have not had a chance to migrate all the insight tests and
documentation yet. You can find some examples of the JSON object
graphs here [12].

The ideal approach would be to provide a Java port of insight and
place it here:

http://github.com/cadorn/insight/tree/master/packages/lib-java

with an API that follows the essence of the PHP implementation.

Once the wildfire and insight projects are ported we can layer debug/
user API's on top. FirePHP 1.0 simply wraps [13] the insight API and
will provide plugins that collect data from PHP frameworks and
libraries without needing the user to manually integrate into popular
stacks.

To get an overview of the data flow you can take a look at the FirePHP
Examples TestRunner [14].

To get the Java port tested and compliant I would encourage you to use
FirePHP Companion [2]. It will be the most complete implementation
going forward with careful consideration to ensure alternative clients
such as FireConsole and Web Inspector stay compatible and with a core
set of features. All FirePHP Companion features will be implemented
via Insight/Wildfire so any client can potentially support the full
feature stack.

I am very exciting about getting all this working with Java and will
support any efforts in this area with great interest. My focus/
contribution to the Java side of things would be to add support for
Narwhal on Rhino [15], RingoJS [16] and Google AppEngine.

I realize this is a lot of info and there is some work involved but I
believe it will be well worth it. I am available for questions and
will make more info available on the internals as needed.

Please don't hesitate to ask for clarification on any aspect.

Looking forward to your thoughts and if the Java port is something we
can work towards together.

Christoph

[1] - http://commonjs.org/
[2] - http://companion.firephp.org/
[3] - http://www.christophdorn.com/Blog/2009/01/16/a-case-for-an-ajax-based-eclipse-project-explorer/
[4] - http://github.com/cadorn/wildfire
[5] - http://github.com/cadorn/insight
[6] - http://github.com/cadorn/renderers
[7] - http://github.com/cadorn/wildfire/tree/master/packages/lib-php/
[8] - http://github.com/cadorn/wildfire/tree/master/packages/lib-js/
[9] - https://bugs.webkit.org/show_bug.cgi?id=30897
[10] - http://reference.developercompanion.com/Tools/FirePHPCompanion/API/
[11] - http://github.com/cadorn/insight/tree/master/packages/lib-php/
[12] - http://github.com/cadorn/fireconsole/tree/master/packages/lib-php/tests/Client/FcObjectGraph/
[13] - http://github.com/cadorn/firephp-libs/tree/master/packages/insight/lib/FirePHP/
[14] - http://reference.developercompanion.com/Tools/FirePHPCompanion/Run/Examples/
[15] - http://narwhaljs.org/
[16] - http://ringojs.org/