On Sat, 07 Nov 2020 19:35:02 +0000 khuxkm at tilde.team wrote: > 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. Indeed, no arguments here, however, large files typically wouldn't need any caching, you download once and save to your disk, these include ISOs, FLACs, JPEGs and so on. And again: > The "first class" application of Gemini is human consumption of > predominantly written material Written material in gemtext wouldn't need caching because it's a few kilobytes. > > 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 you consider keeping the core philosophy (what I suppose it should be) from solutions to non-existent problems elitism, then have fun comforting each other and entertaining bad design choices. Once caching becomes standard, there's nothing stopping servers from serving large content just because major client implementations will cache it anyway, and this turns from optional to *if you don't support it, your client is limited*, what next? And I'm gonna say it again, if the protocol is centered around serving plain text documents, why would caching be a concern? seems to me that just invites extension and the possibility of generalizing the protocol the same way HTTP went.
---
Previous in thread (23 of 55): 🗣️ Ali Fardan (raiz (a) stellarbound.space)
Next in thread (25 of 55): 🗣️ Ali Fardan (raiz (a) stellarbound.space)