Revert "Stabilize transactionWatch to version 1" (#149)

Author: jsdw

src/SUMMARY.md

@@ -44,5 +44,5 @@
     - [transaction_v1_broadcast](api/transaction_v1_broadcast.md)
     - [transaction_v1_stop](api/transaction_v1_stop.md)
   - [transactionWatch](api/transactionWatch.md)
-    - [transactionWatch_v1_submitAndWatch](api/transactionWatch_v1_submitAndWatch.md)
-    - [transactionWatch_v1_unwatch](api/transactionWatch_v1_unwatch.md)
+    - [transactionWatch_unstable_submitAndWatch](api/transactionWatch_unstable_submitAndWatch.md)
+    - [transactionWatch_unstable_unwatch](api/transactionWatch_unstable_unwatch.md)

src/api/transactionWatch_v1_submitAndWatch.md renamed to src/api/transactionWatch_unstable_submitAndWatch.md

@@ -1,17 +1,17 @@
-# transactionWatch_v1_submitAndWatch
+# transactionWatch_unstable_submitAndWatch
 
 **Parameters**:
 
 - `transaction`: String containing the hexadecimal-encoded SCALE-encoded transaction to try to include in a block.
 
 **Return value**: String representing the subscription.
 
-The string returned by this function is opaque and its meaning can't be interpreted by the JSON-RPC client. It is only meant to be matched with the `subscription` field of events and potentially passed to `transactionWatch_v1_unwatch`.
+The string returned by this function is opaque and its meaning can't be interpreted by the JSON-RPC client. It is only meant to be matched with the `subscription` field of events and potentially passed to `transactionWatch_unstable_unwatch`.
 
-Once this function has been called, the server will try to propagate this transaction over the peer-to-peer network and/or include it onto the chain even if `transactionWatch_v1_unwatch` is called or that the JSON-RPC client disconnects. In other words, it is not possible to cancel submitting a transaction.
+Once this function has been called, the server will try to propagate this transaction over the peer-to-peer network and/or include it onto the chain even if `transactionWatch_unstable_unwatch` is called or that the JSON-RPC client disconnects. In other words, it is not possible to cancel submitting a transaction.
 
-The JSON-RPC server must accept at least 4 `transactionWatch_v1_submitAndWatch` subscriptions per JSON-RPC client.
-Trying to open more might lead to a JSON-RPC error when calling `transactionWatch_v1_submitAndWatch`.
+The JSON-RPC server must accept at least 4 `transactionWatch_unstable_submitAndWatch` subscriptions per JSON-RPC client.
+Trying to open more might lead to a JSON-RPC error when calling `transactionWatch_unstable_submitAndWatch`.
 
 ## Notifications format
 
@@ -20,7 +20,7 @@ This function will later generate one or more notifications in the following for
 ```json
 {
     "jsonrpc": "2.0",
-    "method": "transactionWatch_v1_watchEvent",
+    "method": "transactionWatch_unstable_watchEvent",
     "params": {
         "subscription": "...",
         "result": ...
@@ -168,5 +168,5 @@ JSON-RPC servers are allowed to skip sending events as long as it properly keeps
 
 ## Possible errors
 
-- A JSON-RPC error with error code `-32800` can be generated if the JSON-RPC client has already opened 4 or more `transactionWatch_v1_submitAndWatch` subscriptions.
+- A JSON-RPC error with error code `-32800` can be generated if the JSON-RPC client has already opened 4 or more `transactionWatch_unstable_submitAndWatch` subscriptions.
 - A JSON-RPC error with error code `-32602` is generated if the `transaction` parameter is not a valid hex string. Note that no error is produced if the bytes of the `transaction`, once decoded, are invalid. Instead, an `invalid` notification will be generated.

src/api/transactionWatch_v1_unwatch.md renamed to src/api/transactionWatch_unstable_unwatch.md

@@ -1,8 +1,8 @@
-# transactionWatch_v1_unwatch
+# transactionWatch_unstable_unwatch
 
 **Parameters**:
 
-- `subscription`: Opaque string equal to the value returned by `transactionWatch_v1_submitAndWatch`
+- `subscription`: Opaque string equal to the value returned by `transactionWatch_unstable_submitAndWatch`
 
 **Return value**: *null*
 

src/dos-attacks-resilience.md

@@ -34,7 +34,7 @@ The events coming from the blockchain node can be seen as a stream. This stream
 
 However, sending a message to a JSON-RPC client might take a long time, in case the client has (intentionally or not) little bandwidth. The threads that are receiving the stream of events should never wait for a client to be ready to accept more data before sending a notification to it. If the client isn't ready, then the notification must either be added to a send queue or simply discarded. Because queues must be bounded, it is unavoidable to sometimes have to discard some notifications.
 
-Consequently, all functions that consist in sending notifications must be designed having in mind that the queue of notifications to send out must be bounded to a certain value. For example, the queue of notifications for `transactionWatch_v1_submitAndWatch` must have a size of 3. When the queue is full, new notifications must overwrite the notifications already in the queue. The design of all JSON-RPC functions should take into account the fact that this shouldn't result in a loss of important information for the JSON-RPC client.
+Consequently, all functions that consist in sending notifications must be designed having in mind that the queue of notifications to send out must be bounded to a certain value. For example, the queue of notifications for `transactionWatch_unstable_submitAndWatch` must have a size of 3. When the queue is full, new notifications must overwrite the notifications already in the queue. The design of all JSON-RPC functions should take into account the fact that this shouldn't result in a loss of important information for the JSON-RPC client.
 
 ## Distinguishing between light and heavy calls