💾 Archived View for rawtext.club › ~sloum › geminilist › 002973.gmi captured on 2020-10-31 at 14:54:10. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Arav K. nothien at uber.space
Fri Oct 30 16:13:05 GMT 2020
- - - - - - - - - - - - - - - - - - -
On Fri Oct 30, 2020 at 2:38 PM WAT, John Cowan wrote:
I confess to not having read these discussions. But what's the
problem? The server writes an entity-body to the socket and closes
it. The client reads from the socket until it gets EOF (a zero-length
return from read or recv). Done. Gopher has been transmitting binary
files like this forever, and the cognate protocols finger and whois
also do it this way: no length or in-band EOF sequence.
The problem is that clients have no way to know how much stuff they'rereceiving. This would be helpful for interactive clients, so that theycan tell the user some indication of progress, and it would be helpfulfor more constrained programs to know whether or not they can store alltheir input. Both of these points were raised in previous discussions.
It is the particular mime-type that declares what parameters are
meaningful to it. Writing
"text/plain;charset=utf-8;content-length=32767" will not mean anything
to anyone outside the Gemini world and will probably confuse them.
AFAIK, all MIME parsers know to ignore additional MIME parameters. Evenif someone who did not know about this concept were to see such an MIMEtype, the idea is clear. I don't see how including this is a problem.
~aravk | ~nothien