Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Proposed approach to decouple protocol.js fronts from actors.

7 views
Skip to first unread message

Eddy Bruel

unread,
Apr 18, 2016, 8:03:12 AM4/18/16
to dev-developer-tools
I spent some time today pondering what would be the best approach to
decouple protocol.js fronts from actors. Here's what I came up with:

Our goal is to be able to create protocol.js fronts in environments where
the server is not available. Currently, the constructors for these fronts
are defined on the server side. We cannot simply move these constructors to
the client side, because their definition depends on that of the
corresponding actors. In particular, the constructor for each front is
created using a factory function that takes the constructor for the
corresponding actor as argument.

What information does this factory function need from the actor
constructor? Each actor constructor defines a property named actorSpec on
its prototype. This field contains the protocol specification for the
actor. A protocol specification consists of three parts: a list of method
specifications, a list of event specifications, and an optional form type
for the actor. A method specification consists of a request and a response
template. These define the format of the request and response packet,
respectively. An event specification only consists of a request template.
The form type is used to marshal/demarshal the actor itself.

At the moment, protocol.js automatically generates the actorSpec field for
each actor. It does this by iterating over the properties of the prototype
of the actor constructor. For the event specifications and form type, it
looks for properties named "events" and "formType", respectively. For the
method specifications, it looks for properties with a property named
_methodSpec. These methods are assumed to be functions that handle
requests; the _methodSpec property contains the request/response template
for the request. To create such request handlers, protocol.js provides a
function named "method". It takes a function and a request/response
template as argument. It uses the latter to generate the _methodSpec
property on the former.

To decouple fronts from actors, we thus need to decouple the actorSpec
property from the actor constructors. In particular, rather than
automatically generating the actorSpec property from the prototype of the
actor constructor, we define each actorSpec manually, and pass it as an
argument to the factory functions for both the front and actor constructors.

Jason Laster

unread,
Apr 18, 2016, 8:47:12 AM4/18/16
to Eddy Bruel, dev-developer-tools
Thanks Eddy.

I can see a separate actorSpec being a nice win. It will also serve as a
source of documentation similar to chrome's protocol.json
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/protocol.json&q=protocol.json&sq=package:chromium&type=cs>
.
> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

Mike Ratcliffe

unread,
Apr 18, 2016, 11:53:24 AM4/18/16
to dev-devel...@lists.mozilla.org
I remember discussing this with somebody in the past... maybe dcamp but
I am not sure.

If we do this well it really will make our actors easier for people to
understand so this seems like a huge win to me.

/Mike Ratcliffe

Luca Greco

unread,
Apr 18, 2016, 2:03:16 PM4/18/16
to dev-developer-tools, ejpb...@mozilla.com, mratc...@mozilla.com
On Mon, Apr 18, 2016 at 5:53 PM, Mike Ratcliffe <mratc...@mozilla.com>
wrote:

> I remember discussing this with somebody in the past... maybe dcamp but I
> am not sure.
>
> If we do this well it really will make our actors easier for people to
> understand so this seems like a huge win to me.
>
> /Mike Ratcliffe
>
>
I just wanted to add some additional details about this (in case it can be
useful to the analysis):

currently a protocol description of all "protocol.js"-based actors can be
retrieved over the RDP protocol itself,
using a "protocolDescription" requestType sent to the root actor.
(which is handled here:
https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/root.js#485
).

Some times ago we tried to rebuild the client from this protocolDescription
on the client side, the experiment was called volcan:
-
https://dxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/dev/volcan.js
- https://github.com/Gozala/volcan

I remember that at the time the main issues we found were:
- some important actors are not currently defined using "protocol.js"
abstractions,
as a consequence currently they doesn't have an actorSpec to be included
into the json protocol description
(for this reason, in some cases, we polyfilled the json protocol
description with some of the important missing bits,
e.g. for the console actor https://github.com/Gozala/volcan/pull/3/files)
- only the actorSpec of the actors that are already been loaded are
available in the protocolDescription,
any lazy actor not yet created is not in that dump (until we request it
again after loading the actor)

Best,
Luca

Alexandre poirot

unread,
Apr 18, 2016, 2:14:49 PM4/18/16
to Luca Greco, Mike Ratcliffe, Eddy Bruel, dev-developer-tools
+1 Jason
=> It would be great to have a pure JSON description.
Without depending on any JS (especially "Heritage" or any special JS
library).
But I don't think we can reuse their format as-is. We have
hierarchy/nested-actors.
Chrome seems to have only a list of requests sorted by "domain".

+1 Luca.
If we have a pure JSON description, then we could just pipe that via the
protocolDescription request.
protocolDescription already returns such pure JSON view of the actors:
https://github.com/Gozala/volcan/pull/3/files#diff-f50e3511dbc113046cdf1ff4035785e2R87
It is a bit cryptic. We may just tweak that to make it more readable, may
be converge with reusing some patterns of what chrome is using in their
protocol.json...

-1 Luca.
We do not care much about old actors here. Old actors do not force you to
depend on server modules. This is the main issue we are trying to solve
here. It would be great if we could finally have only one kind of
abstraction, but I'm afraid that's still not a blocker.

Jim Blandy

unread,
Apr 18, 2016, 2:31:03 PM4/18/16
to Alexandre poirot, Eddy Bruel, dev-developer-tools, Mike Ratcliffe, Luca Greco
It may be worth keeping in mind that devtools.html, which is our focus this
quarter, is blocked on the protocol.js separation. The status quo is going
to interfere with treating the devtools as an ordinary web page, which I
understand is a very-nice-to-have for all the other work.

So we don't want to discuss re-architecting, or converging with Chrome's
format, or integrating documentation, or anything like that at this point.
We want a landed patch that allows the UI to create the fronts it needs.

Once that's landed, then big plans for improvements and cleanups and
shining new architectures can be prioritized against other work as normal.




On Mon, Apr 18, 2016 at 11:14 AM, Alexandre poirot <poiro...@gmail.com>
wrote:
0 new messages