Christian Seibold krixano at mailbox.org
Sat Jun 19 11:05:54 BST 2021
- - - - - - - - - - - - - - - - - - -
If I understand correctly your proposal, you suggest to change,
neither the protocol nor the gemtext format, but to push browser
authors to recognize text/gemini+gzip and act accordingly.
Ok, so, as you have probably read before :D , there's a divide on whether compression should even be put into the protocol or not. There's even a divide on whether it should be put into any clients - of course nobody can control every client and force them to do what they want it to do. So, realistically, I don't think we can get everyone to agree on a decision about compression being put into the protocol, especially when the protocol is almost finalized.
However, users are allowed to suggest things for browsers, and browser developers are allowed to reject suggestions. So, as we cannot get it in the protocol, then some client developers might decide to implement it in their clients, and it's totally possible to do this. This is really the next best step that we could take, assuming we won't reach a consensus on putting it into the protocol.
However, if what was said before was correct about TLS 1.3 having compression, all of this might be completely unnecessary when we switch to TLS 1.3.
* how the end user of a browser without compression support will know
in advance if the file is compressed or not? From the file extension?
It is not always present.
This is a good point about client design. I think clients should tell the user the mimetype of files that are unrecognized by the client. I would also personally like that they allow the user to open the file in another program, kinda like AV-98's hooks, basically.
* today, every browser can read every Gemini file. Your proposal
seems to imply that some users will now see only a part of the
Geminispace, the uncompressed one. This is the same problem we have
when trying to use the Web with lynx or dillo: we can see only a part
of it.
I mean, right. But what else can we do if we cannot reach a consensus on putting compression in the protocol? Solderpunk could just make the decision anyways, but that's dependent on him. The next best thing is for clients that want to provide this functionality to do so, and for clients that don't - they might or might not allow you to open it in a different program.
We also kinda already have this problem with various filetypes. There's just too many filetypes to support them all in clients, so sending them off to be handled by another program can help resolve this.