txWatch: Stabilize to version 1 (#154)

Signed-off-by: Alexandru Vasile <[email protected]>

Author: lexnv

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_unstable_submitAndWatch](api/transactionWatch_unstable_submitAndWatch.md)
-    - [transactionWatch_unstable_unwatch](api/transactionWatch_unstable_unwatch.md)
+    - [transactionWatch_v1_submitAndWatch](api/transactionWatch_v1_submitAndWatch.md)
+    - [transactionWatch_v1_unwatch](api/transactionWatch_v1_unwatch.md)

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

@@ -1,14 +1,14 @@
-# transactionWatch_unstable_submitAndWatch
+# transactionWatch_v1_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_unstable_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_v1_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_unstable_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_v1_unwatch` is called or that the JSON-RPC client disconnects. In other words, it is not possible to cancel submitting a transaction.
 
 
 ## Notifications format
@@ -18,7 +18,7 @@ This function will later generate one or more notifications in the following for
 ```json
 {
     "jsonrpc": "2.0",
-    "method": "transactionWatch_unstable_watchEvent",
+    "method": "transactionWatch_v1_watchEvent",
     "params": {
         "subscription": "...",
         "result": ...

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

@@ -1,8 +1,8 @@
-# transactionWatch_unstable_unwatch
+# transactionWatch_v1_unwatch
 
 **Parameters**:
 
-- `subscription`: Opaque string equal to the value returned by `transactionWatch_unstable_submitAndWatch`
+- `subscription`: Opaque string equal to the value returned by `transactionWatch_v1_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_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.
+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.
 
 ## Distinguishing between light and heavy calls