Support JSON-RPC 2.0-compatible VM service events.

runtime/vm/service/service.md

 # Dart VM Service Protocol 1.0 (Draft 1)
 
 > Please post feedback to the [observatory-discuss group][discuss-list]
 
 This document describes _draft 1_ of _version 1.0_ of the Dart VM
 Service Protocol.  This protocol is used to communicate with a running
 Dart Virtual Machine.
 
 To use the Service Protocol, start the VM with the *--observe* flag.
 The VM will start a webserver which services protocol requests via WebSocket.
 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**
 
 - [RPCs, Requests, and Responses](#rpcs-requests-and-responses)
 - [Events](#events)
 - [Types](#types)
 - [IDs and Names](#ids-and-names)
 - [Versioning](#versioning)
 - [Private RPCs, Types, and Properties](#private-rpcs-types-and-properties)
 - [Public RPCs](#public-rpcs)
@@ skipping 153 matching lines @@
 
 By using the [streamListen](#streamlisten) and [streamCancel](#streamcancel) RPCs, a client may
 request to be notified when an _event_ is posted to a specific
 _stream_ in the VM. Every stream has an associated _stream id_ which
 is used to name that stream.
 
 Each stream provides access to certain kinds of events. For example the _Isolate_ stream provides
 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"
 }
 ```
 
 It is considered a _backwards compatible_ change to add a new type of event to an existing stream.
 Clients should be written to handle this gracefully.
 
 
+
 ## Types
 
 By convention, every result and event provided by the Service Protocol
 is a subtype of [Response](#response) and has the _type_ property.
 This allows the client to distinguish different kinds of responses. For example,
 information about a Dart function is returned using the [Function](#function) type.
 
 If the type of a response begins with the _@_ character, then that
 response is a _reference_. If the type name of a response does not
 begin with the _@_ character, it is the an _object_. A reference is
@@ skipping 1762 matching lines @@
 ```
 
 ## Revision History
 
 version | comments
 ------- | --------
 1.0 draft 1 | initial revision
 
 
 [discuss-list]: https://groups.google.com/a/dartlang.org/forum/#!forum/observatory-discuss