Caching and sizes, the explosion of responise codes (was Re: Caching and status codes)

[khuxkm at tilde.team]

November 8, 2020 12:52 AM, "Zach DeCook" <zachdecook at librem.one> wrote:

>> We're done out of status codes and crashing into the next block. It
>> may
>> seem silly to worry about future feature now, but hey, the future comes
>> eventually. Even *if* the size doesn't get its own status code, I
>> think my
>> argument stands---features can mix, and if they can mix, the number of
>> status code explodes:
>> 
>> from where
>> I
>> come from, working code is worth more than talk.
> 
> I think there's still a long way for gemini clients to come before demanding the Future Inevitable
> Feature. Like, the more thought that goes into this, the less likely we'll run out of status codes.
> One way a client could implement caching is by loading the cached version of a page, and telling
> the user when it was downloaded, next to a 'refresh' button. A gemini client could even offer a
> diff view between the current page and the cached copy. All of that *empowers the users* over the
> servers, and doesn't rely on adding anything to the spec.
> A "please don't cache" response code would be (ab)used by servers who desire to track their users.
> -Zach

Again, clients are free to ignore the "do not cache" response code as they wish. It would be considered bad form, and it may confuse the everloving hell out of somebody who's requesting a random picture and keeps getting the same one, but you're free to do it, just as you're free to cache any response now.

Just my two cents,
Robert "khuxkm" Miles

(PS: still working on that implementation)