On Mon, 9 Nov 2020 17:18:21 +0100 Philip Linde <linde.philip at gmail.com> wrote: > On Sun, 8 Nov 2020 17:22:56 -0500 > This is unavoidable in any case of adding a sufficient number of > features that can be combined. If every feature proposal should be > evaluated in terms of the slippery slope of "what if we add more" > there wouldn't be a point to discussing additions to the protocol, a > notion that I'm actually partial to, but that I think shouldn't be > used as a basis for judging against individual feature proposals. Lets not look at it this way, lets look at it for the way of what does caching truly enable, I've discussed this many times, no one seemed to address my concerns, if in-protocol caching mechanism exists, it opens the window for serving complex document formats that are resource heavy, see HTML pulling stylesheets and images for example, it is discouraged to use anything other than gemtext for documents in Gemini. In the case of serving media files like music, video, and even large PDFs, these are downloaded to be saved on disk anyway, so caching wouldn't be a concern. The only convincing reasoning for caching is Waweic's use case using Mallick's method, and even that doesn't introduce any new protocol features. > That would be a nice feature, but is it nice enough to warrant > breakage across the growing number of implementations? text/gemini > documents can display an estimated size for linked files, and a user > can configure their automatic client to abort at a certain point or > choose in their interactive client to cancel a request. Not a > complete solution by any means, but worth considering as it is much > cheaper. While to each their own, and implementations can behave the way they desire, I'm against this feature as it breaks certain sites that are slow to load, I'd have to refresh once again and get it to load fast if I don't want it to timeout, what you could do instead is have in the bottom (or top) status bar or any information indicator a display of how much is downloaded of the requested file, the user then judges if they want to stop or not by hitting a cancel button.
---
Previous in thread (48 of 55): 🗣️ Philip Linde (linde.philip (a) gmail.com)
Next in thread (50 of 55): 🗣️ Jason McBrayer (jmcbray (a) carcosa.net)