Caching and status codes

November 7, 2020 11:43 AM, "Ali Fardan" <raiz at stellarbound.space> wrote:

> On Sat, 07 Nov 2020 10:17:20 +0300
> "Leo" <list at gkbrk.com> wrote:
> 
>> I don't understand why a client caching responses is rude. Or rather,
>> I don't understand who it is being rude to. When I configure my HTTP
>> or Gemini browser to cache every response, is my browser now being
>> rude to me? Is it being rude to the server?
> 
> The rude thing here would be having to serve large files over Gemini
> and expect them to be served often, the protocol operates under the
> assumption that caching does not exist, it's by convention, this
> simplifies the client a LOT and removes such uncertainty when writing
> dynamic content for Gemini. Consider reading 2.1.1 in
> gemini://gemini.circumlunar.space/docs/faq.gmi

Alright, bet. 2.1.1 in the FAQ says:

> Gemini aims to be simple, but not too simple. Gopher is simpler at
> a protocol level, but as a consequence the client is eternally
> uncertain: what character encoding is this text in? Is this text the
> intended content or an error message from the server? What kind of 
> file is this binary data? Because of this, a robust Gopher client is
> made less simple by needing to infer or guess missing information. 
> Early Gemini discussion included three clear goals with regard to
> simplicity:
>
> * It should be possible for somebody who had no part in designing
> the protocol to accurately hold the entire protocol spec in their
> head after reading a well-written description of it once or twice.
> * A basic but usable (not ultra-spartan) client should fit
> comfortably within 50 or so lines of code in a modern high-level
> language. Certainly not more than 100.
> * A client comfortable for daily use which implements every single
> protocol feature should be a feasible weekend programming project
> for a single developer.

Adding separate 2x status codes for "feel free to cache this" and 
"don't cache this" would follow:


harder than remembering the status codes that exist today.

got a 20 response code (that's the point of the 2-digit response
code, AFAICT).

a client that "implements every single protocol feature".

>> How can something that causes less resource usage on the server be
>> rude to the server, or something I configured or downloaded as a
>> "client that has caching" be rude to me for using it?
> 
> Because the server operates under the assumption that content is not
> cached, if you're serving large files over Gemini you should look
> somewhere else, this is not bittorrent, and if your server is eating up
> a lot of resources, you're doing Gemini wrong, Gemini servers don't
> have to be complicated, that's your own problem. Consider using
> connection queue and serving connections one by instead of forking or
> multithreading because the protocol allows such simple design by
> closing the connection right after the transaction, it's not like in
> HTTP land where you have keep-alive.

Elitism much? Let me read you 2.1.3, from the very same FAQ you quoted:

> The "first class" application of Gemini is human consumption of
> predominantly written material - to facilitate something like
> gopherspace, or like "reasonable webspace" (e.g. something which is
> comfortably usable in Lynx or Dillo). But, just like HTTP can be, and
> is, used for much, much more than serving HTML, Gemini should be able to
> be used for as many other purposes as possible without compromising the
> simplicity and privacy criteria above. This means taking into account
> possible applications built around non-text files and non-human clients.

I'm not sure how you read this section, but it seems to me like the intent
is to be able to serve large files if you can.

>> Is not doing everything a server sends being rude to the server
>> operator? If a server sends a 100000000x100000000 image, is my image
>> viewer being rude for refusing to decode/display it?
> 
> No, its being sane, this does not apply here.

Let me rephrase the question: if a server tells you you can cache the 
response, is your client being rude for refusing to cache it?

> Does everyone here require a lecture on why their desired features
> aren't in the protocol yet? seems to be the common point of discussion
> here, as if the protocol is NOT ENOUGH, I don't know what brought your
> interest here, did you see it as a great way of avoiding the current
> scope creep of the modern web, or as a playground to satisfy your bad
> ideas?

Again, your elitism is showing. I feel like adding a way to signal 
whether or not you can safely cache a response isn't really sacrificing 
any of the Gemini ethos: simplicity, privacy, or generality.

> If any feature does not add a great value at an acceptable cost to the
> simplicity of the protocol, consider it rejected before even proposing
> it, I don't want to have a different experience browsing Gemini space
> using netcat than using Kristall.

I fail to see how adding "safe to cache" and "do not cache" status codes 
would make using netcat different from Kristall or any other client. Just 
treat it as a 2x success status code, and move on.

Just my two cents,
Robert "khuxkm" Miles

---

Previous in thread (18 of 55): 🗣️ John Cowan (cowan (a) ccil.org)

Next in thread (20 of 55): 🗣️ Nathan Galt (mailinglists (a) ngalt.com)

View entire thread.