chore: update docs

configs/config.toml

@@ -1,15 +1,15 @@
 # Collection of binaries which uplink can spawn as a process
 # This ensures that user is protected against random actions
 # triggered from cloud.
-processes = [{ name = "echo", timeout = 10 }]
+processes = [{ name = "echo" }]
 
 # Map of action names for re-routing on partial completion. An action is considered
 # partially completed when progress is 100, but status is neither "Failed" nor "Completed".
 action_redirections = { "firmware_update" = "install_update", "send_file" = "load_file", "send_script" = "run_script" }
 
 # Script runner allows users to trigger an action that will run an already downloaded
 # file as described by the download_path field of the JSON payload of a download action.
-script_runner = [{ name = "run_script", timeout = 10 }]
+script_runner = [{ name = "run_script" }]
 
 # Location on disk for persisted streams to write backlogs into, also used to write
 persistence_path = "/tmp/uplink/"
@@ -149,7 +149,7 @@ priority = 255
 [downloader]
 actions = [
     { name = "update_firmware" },
-    { name = "send_file", timeout = 10 },
+    { name = "send_file" },
     { name = "send_script" },
 ]
 path = "/var/tmp/ota-file"

docs/apps.md

@@ -73,13 +73,6 @@ An example success response to an action with the id `"123"`, would look like:
 }
 ```
 
-> **NOTE:** There is a timeout mechanism which on being triggered will send a ***Failed*** response to platform and stop forwarding any *Progress* responses from the connected applications. In order to not trigger this timeout, an application must send a ***Failed*** or ***Completed*** response before the action timeout. Once an action has timedout, a failure response is sent and all it's future responses are dropped. Action timeouts can be configured per action when setting up uplink, as follows:
-> ```
-> [tcpapps.main_app]
-> port = 5050
-> actions = [{ name = "abc", timeout = 300 }] # Allow the connected app to send responses for action abc upto 5 minutes from receive, send a failure response and drop all responses afterwards if not yet completed.
-> ```
-
 ## Demonstration
 We have provided examples written in python and golang to demonstrate how you can receive Actions and reply back with either data or responses. You can checkout the examples provided in the `demo/` directory and execute them as such:
 1. Ensure uplink is running on the device, connected to relevant broker and using the following config:

docs/design.md

@@ -52,7 +52,7 @@ Self Instrumentation
 * Total incoming and outgoing data throughput
 * Number of files in disk
 * Total backlog size
-* Rougue data. Receiving data of invalid channels. Report first incident
+* Rogue data. Receiving data of invalid channels. Report first incident
   and frequency for a given time period
 * This can be a hashmap 
 

docs/downloader.md

@@ -6,7 +6,7 @@ As described in the [example `config.toml`](https://github.com/bytebeamio/uplink
 Here is one more example config to illustrate how uplink can be configured:
 ```
 [downloader]
-actions = [{ name = "update_firmware",  timeout = 3600 }] // sets the timeout to 1hr, allowing for uplink to wait for a whole hour before timing out the download, useful for large downloads over slower networks
+actions = [{ name = "update_firmware }]
 path = "/data/local/downloads" // downloads the file into a location commonly seen in Android systems, i.e. /data/local/downloads/update_firmware
 ```