Caching and status codes

On Sun, 08 Nov 2020 00:41:10 +0300
"Leo" <list at gkbrk.com> wrote:
> This is the statement that bothered me because it seemed very weird to
> consider a client "rude" for not making requests. So I asked about it
> for clarification.

Because as of currently, there's no way to indicate if content is
dynamic or static.

> But here you are saying that the rude thing here is having to serve
> large files over gemini and expecting them to be served often. This
> would be the server being rude, and clients caching or not caching
> resources would not have an impact on how large a server's reponses
> are.
>
> If anything, it would result in less traffic and at least partially
> mitigate the issue. If your server is being _rude_ and sending large
> responses, my client is not gonna make it worse by requesting it every
> single time. Your server might have a lot of bandwidth, my client does
> not.

Gemini responses should typically be in the kilobytes range as they are
plain text, unless you're serving MP3s or ISOs which are saved to the
disk permanently, there's no point of having caching here.

> The protocol operates under the assumption that caching does not exist
> in order to make clients and servers simpler. A client adding caching
> would NOT affect a server negatively. If you consider caching clients
> to be rude clients, too bad, you will never notice them because
> instead of making extra requests, they are making less. I suppose you
> can ask them to apologise for not making you spend money on
> compute/bandwidth etc.

Again, the protocol by convention should not go in the direction of
bittorrent, plain text documents aren't large.

> Again, you are talking about making servers more complicated. If my
> client does not cache and your server sends large responses, this is
> indeed a problem and you might have to make your server more complex
> to handle it. Caching clients would make simpler server code
> possible, as performance tricks would not be necessary. But even
> ignoring that, a client that caches responses would not make your
> server more complex.

They won't take burden off the server, instead, they add more, now the
server have to tell the client which content to cache and which it
should not.

> So it is being sane when a server says "display this monstrous image"
> and the client refuses, but it is insane when the server says "please
> download this resource that you downloaded 3 seconds ago" and the
> client says "I'll just use the response I have cached"?

Resources are identified using URIs, that's all the client knows, how
does it know that the resource haven't been altered since the last time
it got accessed? the client could be showing an outdated document in
the case of dynamic content.

> The whole point of the discussion is that clients WILL cache
> resources. Gemini benefits a lot from having a wide range of
> different clients. You simply can't control everyone's use case to
> fit the way you think they should consume content.

Different use cases can be satisfied with different protocols.

> Just like some browsers/proxies cache HTTP and Gopher responses, some
> people who are bandwidth constrained or simply not wasteful will
> choose to cache their Gemini responses too. The discussion throws out
> the idea of client HINTS that will say "This might be a dynamic
> response, maybe don't cache it". Neither the server nor the client
> needs to take advantage of this, a client can always cache or never
> cache, and a server can expect everything to be cached or not cached.
> Just like before.

Again, there shouldn't be a point where caching is mandatory if plain
text documents are being served.

> Disagreeing with someone is one thing, but you don't have to attack
> them like this.

I'm sorry you feel offended.

> Before you shame other people, please enlighten us
> with the tangible value that you have provided to the greater Gemini
> community.

Not proposing solutions to non-existent problems.

> > 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 agree with this completely.

Then there's nothing to discuss further.

---

Previous in thread (24 of 55): 🗣️ Ali Fardan (raiz (a) stellarbound.space)

Next in thread (26 of 55): 🗣️ khuxkm (a) tilde.team (khuxkm (a) tilde.team)

View entire thread.