Cache duration and response body size proposals

[Ali Fardan]

On Tue, 10 Nov 2020 14:17:13 +0000
khuxkm at tilde.team wrote:
> I keep hearing this argument and I don't agree with it one bit. (I'm
> not necessarily disagreeing with *you*, Johann, just in general.)
> 
> One design criterion of Gemini is generality. As the FAQ puts it:
> 
> > 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.  
> 
> It's *possible* to serve large files over Gemini. I can make a script
> that generates a large image (or I can just have a large image to
> serve). Therefore, you should be able to use Gemini to serve large
> files. The main draw I can see for a Content-Length header is being
> able to see if the whole file comes across the wire. The ability to
> resume an interrupted download need not exist; just retry the request
> if all of the content doesn't get across.

Just because it is possible to do this within the protocol doesn't mean
it should accommodate every use case, your use case is possible, but
not recommended, the protocol is designed for serving small text
documents, I said this million times, you just skip it and continue
your push for the "solutions" to non-existent problems in Gemini.

If you believe the protocol is limited, THAT IS BY DESIGN, if it gets
extended to allow the frequent serving of large files then nothing
stopping anyone from developing a new markup language that is meant for
Gemini that serves stylesheets and what not, I know this is against the
Gemini philosophy, but if it is, then the protocol should not provide
means for its possibility.

You have to appreciate that the community give each other a slap on the
wrist for when someone thinks that their proposal is acceptable, for
example, look at my recent suggestion to add escaped lines to gemtext,
it got rejected with valid criticism, It was explained to me it was a
bad idea so I backed off and agreed, I'm thankful for that.

Yet you refuse to address the common concerns brought to you against
your proposal, it seems that every time the mailing list moves on you
come back advocating for such feature again and again, and you get the
exact same replies... move on.

Let me quote Arav K. for you, as he brought up the same points I
brought up previously that you seemed to have ignored anyway:
On Tue, 10 Nov 2020 13:46:30 +0100
"Arav K." <nothien at uber.space> wrote:
> We just had massive discussions about both of these on the ML.  I'll
> provide you with some of my thoughts and consensuses(?) from the
> conversations in the ML:
> 
> > Caching
> > Content-Size / Content-Length  
> 
> Both of these proposals and the general idea around them focuses on
> the transmission of large files.  Caching is geared towards reducing
> request times, and content-size/length aims to provide progress bars
> and size verification.  Content hashing, which you've not discussed,
> is also toward content verification.
> 
> Gemini is focused on serving small textual files.  They clearly do not
> need caching.  Clients that do wish to cache should only cache
> backward and forward in history (i.e. pages that the user had visited
> in the current session), and should provide a reload button at least
> for these pages so that they can be refreshed when needed.  In
> addition, large files are not expected to be requested repeatedly (at
> least, Gemini is not the protocol to do it in), so they do not need
> to be cached.  Small text files are also small enough that their size
> does not need to be known (as they load quickly enough to remove the
> need for progress bars) and they can easily be verified by hand just
> by reading them (the underlying connection is already over TLS, so
> receiving bad data is hard enough as it is).
> 
> Gemini is just not good at large transmissions, and this is
> intentional. If you need to do large transmissions, use other
> protocols that already support content-size (and perhaps
> content-hash), as they are geared towards such transmissions and will
> support it better.