article-tgtimes-most-minimal-gopher-client.md - tgtimes - The Gopher Times | |
git clone git://bitreich.org/tgtimes git://enlrupgkhuxnvlhsf6lc3fziv5h2hhfrinws… | |
Log | |
Files | |
Refs | |
Tags | |
README | |
--- | |
article-tgtimes-most-minimal-gopher-client.md (3604B) | |
--- | |
1 # Most minimal gopher client by tgtimes | |
2 | |
3 Gopher is a protocol allowing browsing text, images interactively, | |
4 reach telnet interfaces, and download any file, or open any URL, | |
5 for custom action to be chosen by the user. | |
6 | |
7 ## "Network" | |
8 One reliable way to fetch the content from internet would be Ethernet, | |
9 but convenience and price would push toward using radio transmission | |
10 such as WiFi. | |
11 | |
12 Ethernet would require an extra transceiver chip, while wifi takes mostly | |
13 just a wire acting as antenna, which partly explains its low cost. | |
14 | |
15 ## "Processing" | |
16 One inexpensive family of processors featuring a high cost-to-performance | |
17 ratio, which also features WiFi, is the ESP32. The C3 iteration even uses | |
18 the open-source architecture RISC-V. The speed is decent enough for | |
19 decoding JPEG an PNG, or support TLS as used in gophers://. | |
20 | |
21 ## "Display" | |
22 The cost of displays have dropped considerably as they invaded the marke… | |
23 Economy of scale made small color displays even cheaper than | |
24 character-based displays. | |
25 | |
26 ## "Input" | |
27 Browsing content is a lot about scrolling. Since we do custom hardware, | |
28 capacitive touch buttons can be used for little to no extra cost. | |
29 This could permit a smooth scrolling through the content. | |
30 | |
31 Once again, mostly requiring wires, this cuts the price and explain | |
32 their popularity. | |
33 | |
34 ## "Text" | |
35 Text is compact and efficient, and bitmap font requires a bit of storage | |
36 for all the common non-ASCII characters, but ESP32 have 16MB of flash | |
37 storage enough for the entire uncompressed Unifont: | |
38 | |
39 http://unifoundry.com/unifont/ | |
40 | |
41 ## "Audio" | |
42 Producing sound does not cost much more than a small audio amplifier, | |
43 software for decoding MP3, and a 3.5mm Jack connector. | |
44 Very small cost added. | |
45 | |
46 ## "Extension" | |
47 an USB interface would allow plugging the device to a computer for | |
48 either automation or using a full keybaord. | |
49 | |
50 ## "Power" | |
51 A small dedicated battery could be included increasing the cost, | |
52 but getting all power from USB would also preserve the choice to | |
53 the user, free to chose a wall charger or portable power bank. | |
54 | |
55 ## "Enclosure" | |
56 A custom 3D printed case would allow keeping the cost very low | |
57 even at small volume production. | |
58 | |
59 There exist boards around 5 USD which would provide all of the above | |
60 except audio and a few wires, typically the size of an MP3 player. | |
61 The grand total bill of material could realistically approach 10 USD. | |
62 An actual product could eventually reach as low as 15 USD if keeping | |
63 only a small margin for the seller, and eventually lower if produced | |
64 on a larger scale. | |
65 | |
66 The support of TLS does not bring any cost in this example: an ESP8266 | |
67 could be used at around 0.85 USD instead of 1.25 USD for the ESP32-C3, | |
68 but is also capable of TLS. | |
69 Image decoding would then probably be much slower. | |
70 By far the most resource hungry part of this project. | |
71 | |
72 Writing the software for such a product from the ground up could take | |
73 typically an entire week, including JPEG and PNG decoding libraries, | |
74 image and font rendering, writing driver for all the parts involved, | |
75 integrating the TCP/IP stack and TLS stack. | |
76 | |
77 While an XML parser able to fetch content over HTTP would be relatively | |
78 as difficult to build, this would not permit the same level of user | |
79 experience as the Gopher-based project: CSS and JavaScript are becoming | |
80 an increasingly frequent requirement to access the Web, and reimplementi… | |
81 a new compatible rendering engine is not feasible to a single person. | |
82 | |
83 This requirement would in turn affect the minimal performance of the | |
84 processing unit used: a processor in the GHz range with RAM in the | |
85 GB range, in particular if anticipating future needs of the Web | |
86 software system. |