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 :)
This was discussed previously in the following thread: gemini://gemi.dev/gemini-mailing-list/messages/000012.gmi Which I'm now going to re-read to remind myself of what was said. From memory, I wasn't keen about adding extra fields to the META part of the response header, for my usual fear of opening the gates to people adding on weird non-standard extensions once it's established that more than exactly one thing is allowed there. Interestingly, I somehow forgot about this ubiquitous fear of mine with regards 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 :)
On 1/18/20 6:34 PM, solderpunk wrote: > This was discussed previously in the following thread: > > gemini://gemi.dev/gemini-mailing-list/messages/000012.gmi > > Which I'm now going to re-read to remind myself of what was said. From > memory, I wasn't keen about adding extra fields to the META part of the > response header, for my usual fear of opening the gates to people adding > on weird non-standard extensions once it's established that more than > exactly one thing is allowed there. > > Interestingly, I somehow forgot about this ubiquitous fear of mine with > regards to the recent proliferation of text/gemini line types... Ah yes fogot about that thread! Basically Sean's proposal gemini://gemi.dev/gemini-mailing-list/messages/000045.gmi would satisfy all my needs client-wise, but if you prefer not to go this route that's fine too. Kind of a cherry on top of the cake!
julienxx writes: > Could we imagine a standardized way to query an URL just for it's meta header maybe? I have just been requesting the document reading the first line and then severing the connection. I do agree that having content size, pref in bytes, in the meta would allow for loading animations, percent counters, download managers, etc. Which would benefit the user of any client. --? Sent with https://mailfence.com Secure and private email
On Sat, Jan 18, 2020 at 06:58:26PM +0100, Brian Evans wrote: > julienxx writes: > > Could we imagine a standardized way to query > an URL just for it's meta header maybe? > > I have just been requesting the document reading > the first line and then severing the connection. > > > I do agree that having content size, pref in bytes, in > the meta would allow for loading animations, > percent counters, download managers, etc. Which > would benefit the user of any client. I guess the question is whether we prefer adding this information into the response header and having clients do the request-and-terminate trick, or defining a well-known endpoint servers can implement which takes a path as an input and returns either what the response header would be, or maybe a small JSON structure of metadata (which could include stuff like last-modified date). Cheers, Solderpunk
solderpunk <solderpunk at SDF.ORG> writes:
> I guess the question is whether we prefer adding this information into
> the response header and having clients do the request-and-terminate
> trick, or defining a well-known endpoint servers can implement which
> takes a path as an input and returns either what the response header
> would be, or maybe a small JSON structure of metadata (which could
> include stuff like last-modified date).
Personally, I feel like request-and-terminate is the better approach;
it's easier on server developers to correctly handle dropped connections
(which you have to do anyway), as opposed to implementing a separate
route for dynamically-generated metadata responses. I'm strongly against
returning JSON metadata, because it opens the door to unlimited
extensibility.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
Julien Blanchard <julien at typed-hole.org> writes:
> Thanks to gemini://konpeito.media I noticed we might be missing the
> content size information in some cases, mostly binary files.
After finally being on my laptop at home since bookmarking
konpeito.media a month ago, I've come to agree with this. We really need
to include content-length in some way.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
---
Previous Thread: [ANN] Announcing free Gemini hosting at gemini.circumlunar.space