On Sun, 8 Nov 2020 17:22:56 -0500 Sean Conner <sean at conman.org> wrote: > I don't agree that this is self-inflicted on me---what I'm trying (and > failing) to point out is that adding mroe success calls *could* lead to > combinatorial hell. 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. > No, that was to prisonpotato at tilde.team---they were the first to come up > with the idea, not me. I just implemented it first (much the same way I > implemented the first Gemini server even before solderpunk did [1]). Also, > the size breaking code is only active on one link on my site, not everwhere. Okay, I'm glad that you picked it up even when it wasn't addressed directly at you. Consider the option, and why I believe that using the 2x range is inappropriate. > The concern is over large responses. It wasn't much of a concern until > gemini://konpeito.media/ was created and serving up large audio files (and > archives of said audio files). I can envision a client being configured to > abort the download if say, a 10 megabyte file is being downloaded. It > *sucked* when my DSL went down in late September/early October (yes, about > three weeks) and I had to rely upon my cellphone hot spot. I didn't have a > large data plan for the cell phone becuase I didn't need it, until I did. > It would have been nice to configure my web browser to not download anything > over 5M at that point. 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. No-cache/please-cache 2x responses however seem like they can add a lot of value for very little cost. Existing client implementations will be compatible, and the idea of the second digit as a hint from the server that can be ignored by a simpler client is retained. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/695c 2fca/attachment-0001.sig>
---
Previous in thread (47 of 55): 🗣️ marc (marcx2 (a) welz.org.za)
Next in thread (49 of 55): 🗣️ Ali Fardan (raiz (a) stellarbound.space)