Gemini file downloading client - a thought experiment

Emery <ehmry at posteo.net> wrote:

> On Dienstag, 3. November 2020 22:35:14 CET, Katarina Eriksson wrote:
> > This is in response to the thread on content length. I propose making a
> > supporting specification separate from the Gemini specification.
> >
> > Feel free to extend the experiment with more problems and scenarios or
> > point out if I made the wrong conclusion.
>
> Please, just use http or rsync or even better, magnet links for
> directing to bulk data. GUS stats already show that there are ~1.5
> octet-stream links for each Gemini page.
>
> Cheers
> E.
>

Yes, I agree. There are plenty of other protocols to choose from which are
better suited for transferring large files. But that's beside the point.

The purpose of this thought experiment is to find a use case where you
can't work within the constraints and have to add a content length header.

My expectation is that there are no such use case, certainly not one worth
braking compatibility for, but I'm keeping an open mind.

New people will join and ask for a content length header again in a few
months. It has happened before, more than once, in this very young mailing
list. If we would have a supporting specification which deals with this, we
would have something to point at.

Anyone who want to join me in my experiment?

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201104/c4ad
cd1a/attachment.htm>

---

Previous in thread (3 of 9): 🗣️ Ali Fardan (raiz (a) stellarbound.space)

Next in thread (5 of 9): 🗣️ acdw (acdw (a) acdw.net)

View entire thread.