article-tgtimes-most-minimal-gopher-client.md - tgtimes - The Gopher Times
 (HTM) git clone git://bitreich.org/tgtimes git://enlrupgkhuxnvlhsf6lc3fziv5h2hhfrinws65d7roiv6bfj7d652fid.onion/tgtimes
 (DIR) Log
 (DIR) Files
 (DIR) Refs
 (DIR) Tags
 (DIR) 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 market.
           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 reimplementing
           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.