@@ -29,3 +29,85 @@ via webrepl.html client). Run
29
29
to see usage information. Note that there can be only one active
30
30
WebREPL connection, so while webrepl.html is connected to device,
31
31
webrepl_cli.py can't transfer files, and vice versa.
32
+
33
+
34
+ Technical details
35
+ -----------------
36
+
37
+ WebREPL is the latest standard (in the sense of an Internet RFC) for
38
+ communicating and controlling a MicroPython-based board. Following
39
+ were the requirements for the protocol design:
40
+
41
+ 1 . Single connection/channel, multiplexing terminal access, filesystem
42
+ access, and board control.
43
+
44
+ 2 . Network ready and Web technologies ready (allowing access directly
45
+ from a browser with an HTML-based client).
46
+
47
+ Based on these requirements, WebREPL uses single connection over
48
+ [ WebSocket] ( https://en.wikipedia.org/wiki/WebSocket ) as a transport
49
+ protocol. Note that while WebREPL is primarily intended for network
50
+ (usually, wireless) connection, due to its single-connection,
51
+ multiplexed nature, the same protocol can be used over a lower-level,
52
+ wired connection like UART, SPI, I2C, etc.
53
+
54
+ Few other traits of WebREPL:
55
+
56
+ 1 . It is intended (whenever possible) to work in background, i.e.
57
+ while WebREPL operations are executed (like a file transfer), normal
58
+ REPL/user application should continue to run and be responsive
59
+ (though perhaps with higher latency, as WebREPL operations may
60
+ take its share of CPU time and other system resources). (Some
61
+ systems may not allow such background operation, and then WebREPL
62
+ access/operations will be blocking).
63
+
64
+ 2 . While it's intended to run in background, like a Unix daemon,
65
+ it's not intended to support multiple, per-connection sessions.
66
+ There's a single REPL session, and this same session is accessible
67
+ via different media, like UART or WebREPL. This also means that
68
+ there's usually no point in having more than one WenREPL connection
69
+ (multiple connections would access the same session), and a
70
+ particular system may actually limit number of concurrent
71
+ connections to ease implementation and save system resources.
72
+
73
+ WebREPL protocol consists of 2 sub-protocols:
74
+
75
+ * Terminal protocol
76
+
77
+ This protocol is finalized and is very simple in its nature, akin
78
+ to Telnet protocol. WebSocket "text"-flagged messages are used to
79
+ communicate terminal input and output between a client and a WebREPL-
80
+ enabled device (server). There's a guaranteed password prompt, which
81
+ can be detected by the appearance of characters ':', ' ' (at this
82
+ point, server expected a password ending with '\n' from client).
83
+ If you're interested to develop a 3rd-party application to communicate
84
+ using WebREPL terminal protocol, the information above should be enough
85
+ to implement it (or feel free to study implementation of the official
86
+ clients in this repository).
87
+
88
+ * File transfer/board control protocol
89
+
90
+ This protocol uses WebSocket "binary"-flagged messages. At this point,
91
+ this protocol is in early research/design/proof-of-concept phase. The
92
+ only available specification of it is the reference code implementation,
93
+ and the protocol is subject to frequent and incompatible changes.
94
+ The ` webrepl_cli.py ` module mentioned above intended to be both a
95
+ command-line tool and a library for 3rd-party projects to use, though
96
+ it may not be there yet. If you're interested in integrating WebREPL
97
+ transfer/control capabilities into your application, please submit
98
+ a ticket to Github with information about your project and how it is
99
+ useful to MicroPython community, to help us prioritize this work.
100
+
101
+ While the protocol is (eventually) intended to provide full-fledged
102
+ filesystem access and means to control a board (all subject to
103
+ resource constraints of a deeply embedded boards it's intended to
104
+ run on), currently, only "get file" and "put file" operations are
105
+ supported. As above, sharing information with us on features you
106
+ miss and how they can be helpful to the general MicroPython
107
+ community will help us prioritize our plans. If you're interested
108
+ in reducing wait time for new features, you're also welcome to
109
+ contribute to their implementation. Please start with discussing
110
+ the design first, and with small changes and improvements. Please
111
+ keep in mind that WebREPL is just one of the many features on which
112
+ MicroPython developers work, so having sustainable (vs revolutionary)
113
+ development process is a must to have long-term success.
0 commit comments