💾 Archived View for rawtext.club › ~sloum › geminilist › 000365.gmi captured on 2020-09-24 at 02:37:21. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Sat Jan 18 17:34:19 GMT 2020
- - - - - - - - - - - - - - - - - - - ``` This was discussed previously in the following thread: https://lists.orbitalfox.eu/archives/gemini/2019/000012.html Which I'm now going to re-read to remind myself of what was said. Frommemory, I wasn't keen about adding extra fields to the META part of theresponse header, for my usual fear of opening the gates to people addingon weird non-standard extensions once it's established that more thanexactly one thing is allowed there. Interestingly, I somehow forgot about this ubiquitous fear of mine withregards to the recent proliferation of text/gemini line types... Cheers,Solderpunk On Sat, Jan 18, 2020 at 06:05:35PM +0100, Julien Blanchard wrote: > Thanks to gemini://konpeito.media I noticed we might be missing the > content size information in some cases, mostly binary files. > With content that takes some time to be downloaded it would be nice to > be able to show the user the download progress. Most clients currently > leave the user in the dark regarding what's happening. Since I hope > that Gemini will be used for more medium than text as cat uses it, > this would be a nice addition to clients. > I would imagine this added meta only for non `text/whatever` content. > > There is also another need I felt being a client developer, it's > knowing what mime type an URL will return to be able to treat/display > it differently without necessarily getting the content.? Could we > imagine a standardized way to query an URL just for it's meta header > maybe? > > These are really client dev concerns and I feel this might be overkill > and going against the simplicity we want but I had to ask :)