[Webkit-unassigned] [Bug 30897] Web Inspector: Support Debugging via HTTP Headers like FirePHP and FireLogger

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30897





--- Comment #6 from Christoph Dorn <christoph at christophdorn.com>  2010-05-06 17:39:37 PST ---
(In reply to comment #5)
> The current state of the web inspector integration can be found at
> http://github.com/sthulbourn/WebKit-FirePHP

It should be trivial for you to splice in the wildfire JS library [1] to handle
the header parsing. It would provide the greatest ongoing compatibility for the
existing JsonStream and the more advanced Component protocol I am working on.

[1] - http://github.com/cadorn/wildfire/tree/master/packages/lib-js/


> We too had the idea of implementing basic Wildfire support with handlers for
> different plugins/structures, so it could decode the headers and dispatch
> payloads to the responsible handlers (e.g. there would be a handler for
> http://meta.firephp.org/Wildfire/Structure/FirePHP/FirebugConsole/0.1 that
> knows what the FirePHP payloads look like and how to render it).

The JS library mentioned above provides the message routing for that use-case:

var receiver = WILDFIRE.Receiver();
receiver.setId("<Receiver URI which is typically a URL>");
receiver.addListener({
    onMessageReceived: function(context, message) {
        var meta = message.getMeta();
        var data = message.getData();
    }
});

var channel = WILDFIRE.HttpHeaderChannel();
channel.addReceiver(receiver);

// Run received headers through:
channel.parseReceived([
    { "name": "x-wf-...", "value": "..."},
    { "name": "...", "value": "..."}
], context);

A decoder then takes in the "meta" and "data" variables that contain the raw
ASCII of the message and it looks like you already have that working for the
FirePHP structures.


> As far as I understand, a bunch of headers could look like this:
> 
> X-Wf-Protocol-1     http://meta.wildfirehq.org/Protocol/JsonStream/0.2
> X-Wf-1-Plugin-1    
> http://meta.firephp.org/Wildfire/Plugin/FirePHP/Library-FirePHPCore/0.3
> X-Wf-1-Structure-1 
> http://meta.firephp.org/Wildfire/Structure/FirePHP/FirebugConsole/0.1
> X-Wf-1-1-1-1        62|[{"Type":"LOG","File":" ... 

The message headers are composed as follows:

X-Wf-<protocol>-<structure>-<plugin>-<messageIndex>

The protocol is included for each message and specifies how the remaining parts
are to be interpreted. i.e. anything after "X-Wf-<protocol>-"
This allows more than one protocol to coexist in the same set of headers.


> difference
> between plugins and structures is (assuming right now that the plugin is simply
> for informational purposes, and the structure actually influences the message
> payload formats).

Correct. The plugin is for informational purposes only and the structure
determines the format of the message and the target. This aspect was not very
well thought out in the original design which the new Component protocol fixes.

The Component protocol is structured as follows:

x-wf-protocol-1:
http://registry.pinf.org/cadorn.org/wildfire/@meta/protocol/component/0.1.0
x-wf-1-1-receiver: http://pinf.org/cadorn.org/fireconsole
x-wf-1-1-1-sender: http://pinf.org/cadorn.org/wildfire/packages/lib-js
x-wf-1-1-1-1: 23|{"line":10}|Hello World|
x-wf-1-index: 1

The layout of the header names is easier to follow and a message is targeted at
a receiver while disclosing the sender. For now a receiver ID is specific to a
client and implies a certain format and target. I am not sure yet how that will
play out in terms of server library compatibility between FireConsole,
WebInspector and other clients.

To provide interoperability I am considering the following:

1) Use client agnostic receiverIDs such as
http://registry.pinf.org/cadorn.org/wildfire/@meta/receiver/console/<version>
once a common set of functionality and equivalent targets are implemented in
several clients.

2) The client discloses available targets to the server library via request
headers:

x-wf-protocol-1:
http://registry.pinf.org/cadorn.org/wildfire/@meta/protocol/announce/0.1.0
x-wf-1: {"<receiverID>": {"supports": ["<supportID>"]}}

Where <supportID> is client agnostic and used by server libraries to determine
the <receiverID> for the
http://registry.pinf.org/cadorn.org/wildfire/@meta/receiver/console/log/<version>
functionality for example.


All this protocol detail is taken care of by the wildfire JS library mentioned
above which also has the capability to make a secondary request for logging
data based on a key sent by the server instead of the logging data. This is a
commonly requested feature to bypass limits proxies and some servers set on the
size of headers and will be supported by the next version of the server
libraries I am in the process of completing. I already use it with Google
AppEngine.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.