On Sat, Nov 7, 2020 at 11:44 AM Ali Fardan <raiz at stellarbound.space> wrote:
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
>
If clients aren't free to cache, then I'm not free to save a .gmi file on
my file system. That's all a client-side cache is.
> 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.
>
The advantages of not serving connections one by one is that it provides
better service to clients on a heavily-used server. Right now there are no
heavily-used servers, but there's nothing in the Gemini ethos that says
"documents should only be of interest to a few". That's sheer elitism.
> Does everyone here require a lecture on why their desired features
> aren't in the protocol yet?
Client caching has nothing to do with the protocol. The idea of 22 is that
authors (not servers) may want to advise clients against caching in a
particular case.
Do you have anything else to help the community with?
>
"I'm thinking! I'm thinking!" --Jack Benny during a holdup
> 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.
>
If you are browsing with netcat, caching is not even an issue. If nobody
wanted to serve dynamic content, 22 wouldn't be useful. It is handy for
those who do want to, to communicate their intent. No client and no server
has to implement this.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
A witness cannot give evidence of his age unless he can remember being born.
--Judge Blagden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201107/7ccd
309e/attachment.htm>
---
Previous in thread (17 of 55): 🗣️ Martin Keegan (martin (a) no.ucant.org)
Next in thread (19 of 55): 🗣️ khuxkm (a) tilde.team (khuxkm (a) tilde.team)