repo: gemini-site
action: commit
revision: 
path_from: 
revision_from: 709070d249f8d2ada288c2723ce37dd8f526f796:
path_to: 
revision_to: 

commit 709070d249f8d2ada288c2723ce37dd8f526f796
Author: Solderpunk 
Date:   Sun Jun 7 10:45:24 2020 +0000

    FAQ updates.

diff --git a/docs/faq.gmi b/docs/faq.gmi

--- a/docs/faq.gmi
+++ b/docs/faq.gmi
@@ -78,31 +78,48 @@ Gemini allows for:
 * Redirects to prevent broken links when content moves or is rearranged.
 * Domain-based virtual hosting.

+Text in Gemini documents is wrapped by the client to fit the device's viewport, rather than being "hard wrapped" at ~80 characters with newline characters.  This means content displays equally well on phones, tablets, laptops and desktops.
+
 Gemini does away with Gopher's strict directory / text dichotomy and lets you insert links in prose.

 Gemini mandates the use of TLS encryption.

-## 2.3 Which shortcomings of the web does Gemini overcome?
+## 2.3 Is Gopher's directory / text dichotomy *really* a shortcoming?
+
+Modern usage habits in the phlogosphere would seem to suggest that many people think it is.  An increasing number of users are serving content which is almost entirely text as item type 1, so that they can insert a relatively small number of "in line" links to other gopher content, providing some semblence of HTML's hyperlinking - a perfectly reasonable and inoffensive thing to want to do.  Without taking this approach, the best Gopher content authors can do is to paste a list of URLs at the bottom of their document, for their readers to manually copy and paste into their client.  This is not exactly a pleasant user experience.  But forcing hyperlinks into Gopher this way isn't just an abuse of the semantics of the Gopher protocol, it's also a surprisingly inefficient way to serve text, because every single line has to have an item type of i and a phony selector, hostname and port transmitted along with it to make a valid Gopher menu.  Any and all claims to simplicity and beauty which Gopher might have are destroyed by this.  Gemini takes the simple approach of letting people insert as many or as few links as they like into their text content, with extremely low overhead, but retains the one-link-per-line limitation of Gopher which results in clean, list-like organisation of content.  It's hard to see this as anything other than an improvement.
+
+Of course, if you really like the Gopher way, nothing in Gemini stops you from duplicating it.  You can serve item type 0 content with a MIME type of text/plain, and you can write text/gemini documents where every single line is a link line, replicating the look and feel of a RFC1436-fearing Gopher menu without that pesky non-standard i item type.
+
+## 2.4 Which shortcomings of the web does Gemini overcome?

 Gemini contains no equivalent of User-Agent or Referer headers, and the request format is not extensible so that these cannot be shoehorned in later.  In fact, Gemini requests contain nothing other than the URL of the resource being requested.  This goes a very long way to preventing user tracking.

 The "native content type" of Gemini (analogous to HTML for HTTP(S) or plain text for Gopher) never requires additional network transactions (there are no in-line images, external stylesheets, fonts or scripts, no iframes, etc.).  This allows for quick browsing even on slow connections and for full awareness of and control over which hosts connections are made to.

-The native content type of Gemini is strictly a document, with no facility for scripting.
+The native content type of Gemini is strictly a document, with no facility for scripting, allowing for easy browsing even on old computers with limited processor speed or memory.

-## 2.4 Is Gopher's directory / text dichotomy really a shortcoming?
+## 2.5 Does Gemini have any shortcomings of it's own?

-Modern usage habits in the phlogosphere would seem to suggest that many people think it is.  An increasing number of users are serving content which is almost entirely text as item type 1, so that they can insert a relatively small number of "in line" links to other gopher content, providing some semblence of HTML's hyperlinking - a perfectly reasonable and inoffensive thing to want to do.  Without taking this approach, the best Gopher content authors can do is to paste a list of URLs at the bottom of their document, for their readers to manually copy and paste into their client.  This is not exactly a pleasant user experience.  But forcing hyperlinks into Gopher this way isn't just an abuse of the semantics of the Gopher protocol, it's also a surprisingly inefficient way to serve text, because every single line has to have an item type of i and a phony selector, hostname and path transmitted along with it to make a valid Gopher menu.  Any and all claims to simplicity and beauty which Gopher might have are destroyed by this.  Gemini takes the simple approach of letting people insert as many or as few links as they like into their text content, with extremely low overhead, but retains the one-link-per-line limitation of Gopher which results in clean, list-like organisation of content.  It's hard to see this as anything other than an improvement.
+Naturally!

-Of course, if you really like the Gopher way, nothing in Gemini stops you from duplicating it.  You can serve item type 0 content with a MIME type of text/plain, and you can write text/gemini documents where every single line is a link line, replicating the look and feel of a RFC1436-fearing Gopher menu without that pesky non-standard i item type.
+Gemini has no support for caching, compression, or resumption of interrupted downloads.  As such, it's not very well suited to distributing large files, for values of "large" which depend upon the speed and reliability of your network connection.

-## 2.5 How can you say Gemini is simple if it uses TLS?
+## 2.6 How can you say Gemini is simple if it uses TLS?

 Some people are upset that the TLS requirement means they need to use a TLS library to write Gemini code, whereas e.g. Gopher allows them full control by writing everthing from scratch themselves.

 Of course, even a "from scratch" Gopher client actually depends crucially on thousands of lines of complicated code written by other people in order to provide a functioning IP stack, DNS resolver and filesystem.  Using a TLS library to provide a trustworthy implementation of cryptography is little different.

-## 2.6 Why don't you care about retrocomputing support?
+## 2.7 Why didn't you just use Markdown instead of defining text/gemini?
+
+The text/gemini markup borrows heavily from Markdown, which might prompt some people to wonder "Why not just use Markdown as the default media type for Gemini?  Sure, it's complicated to implement, but like TLS there are plenty of libraries available in all the major languages".  Reasons not to go down this route include:
+
+* There are actually many subtly different and incompatible variants of Markdown in existence, so unlike TLS all the different libraries are not guaranteed to behave similarly.
+* The vast majority of Markdown libraries don't actually do anything more than convert Markdown to HTML, which for a simple Gemini client is a needless intermediary format which is heavier than the original!
+* Many Markdown variants permit features which were not wanted for Gemini, e.g. inline images.
+* A desire to preserve Gopher's requirement of "one link per line" on the grounds that it encourages extremely clear site designs.
+
+## 2.8 Why don't you care about retrocomputing support?

 Gopher is so simple that computers from the 80s or 90s can easily implement the protocol, and for some people this is one of the great virtues of Gopher.  The TLS requirement of Gemini limits it to more modern machines.

-----END OF PAGE-----