Support JSON-RPC 2.0-compatible VM service events.

This adds a parameter to streamListen that will cause it to produce JSON-RPC
2.0-compatible events.

R=turnidge@google.com

Review URL: https://codereview.chromium.org//1257943003 .
This commit is contained in:
Natalie Weizenbaum 2015-07-28 17:17:40 -07:00
parent 8e71ddba47
commit 61ea0618ce
4 changed files with 36 additions and 24 deletions

View file

@ -81,6 +81,9 @@
### VM Service Protocol Changes
* **BREAKING** The service protocol now sends JSON-RPC 2.0-compatible
server-to-client events.
* The service protocol now includes a `"jsonrpc"` property in its responses, as
opposed to `"json-rpc"`.

View file

@ -204,11 +204,11 @@ abstract class CommonWebSocketVM extends VM {
bytes.offsetInBytes + offset,
bytes.lengthInBytes - offset);
var map = _parseJSON(meta);
if (map == null) {
if (map == null || map['method'] != 'streamNotify') {
return;
}
var event = map['event'];
var streamId = map['streamId'];
var event = map['params']['event'];
var streamId = map['params']['streamId'];
postServiceEvent(streamId, event, data);
});
}
@ -218,9 +218,10 @@ abstract class CommonWebSocketVM extends VM {
if (map == null) {
return;
}
var event = map['event'];
if (event != null) {
var streamId = map['streamId'];
if (map['method'] == 'streamNotify') {
var event = map['params']['event'];
var streamId = map['params']['streamId'];
postServiceEvent(streamId, event, null);
return;
}

View file

@ -681,8 +681,11 @@ void Service::HandleEvent(ServiceEvent* event) {
ASSERT(stream_id != NULL);
{
JSONObject jsobj(&js);
jsobj.AddProperty("event", event);
jsobj.AddProperty("streamId", stream_id);
jsobj.AddProperty("jsonrpc", "2.0");
jsobj.AddProperty("method", "streamNotify");
JSONObject params(&jsobj, "params");
params.AddProperty("streamId", stream_id);
params.AddProperty("event", event);
}
PostEvent(stream_id, event->KindAsCString(), &js);
}

View file

@ -12,10 +12,9 @@ It is possible to make HTTP (non-WebSocket) requests,
but this does not allow access to VM _events_ and is not documented
here.
The Service Protocol is based on JSON-RPC 2.0
(http://www.jsonrpc.org/specification). The Service Protocol has been
extended to support pushing _events_ to the client, which is
apparently outside the scope of the JSON-RPC specification.
The Service Protocol uses [JSON-RPC 2.0][].
[JSON-RPC 2.0]: http://www.jsonrpc.org/specification
**Table of Contents**
@ -189,22 +188,27 @@ Each stream provides access to certain kinds of events. For example the _Isolate
access to events pertaining to isolate births, deaths, and name changes. See [streamListen](#streamlisten)
for a list of the well-known stream ids and their associated events.
Events arrive asynchronously over the WebSocket and always have the
_streamId_ and _event_ properties:
Stream events arrive asynchronously over the WebSocket. They're structured as
JSON-RPC 2.0 requests with no _id_ property. The _method_ property will be
_streamNotify_, and the _params_ will have _streamId_ and _event_ properties:
```
```json
{
"event": {
"type": "Event",
"kind": "IsolateExit",
"isolate": {
"type": "@Isolate",
"id": "isolates/33",
"number": "51048743613",
"name": "worker-isolate"
"json-rpc": "2.0",
"method": "streamNotify",
"params": {
"streamId": "Isolate",
"event": {
"type": "Event",
"kind": "IsolateExit",
"isolate": {
"type": "@Isolate",
"id": "isolates/33",
"number": "51048743613",
"name": "worker-isolate"
}
}
}
"streamId": "Isolate"
}
```
@ -212,6 +216,7 @@ It is considered a _backwards compatible_ change to add a new type of event to a
Clients should be written to handle this gracefully.
## Types
By convention, every result and event provided by the Service Protocol