URI: 

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