💾 Archived View for rawtext.club › ~sloum › geminilist › 000365.gmi captured on 2020-11-07 at 01:26:23. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Adding a content size meta?

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 :)