<-- back to the mailing list

a space case for transparent gemtext compression

Omar Polo op at omarpolo.com

Sat Jun 19 11:51:28 BST 2021

- - - - - - - - - - - - - - - - - - - 

Christian Seibold <krixano at mailbox.org> writes:

Let me repeat this... adding compression to clients in the way that
has been described in this thread does NOT break geminispace.

I'm not too too sure about this. As I see it, using *any* file typeother than text/gemini as default choice for the content will break thegeminispace.

Gemini browser have to implement text/gemini[0], not text/gemini+gzip,text/html or text/x-markdown, and if text/gemini+gz (or whatever) startsto gain a bit of popularity it *will* break the geminispace IMHO.

Gemini deliberately allows you to send whatever you want over. It's a
file-transfer protocol. Using the mimetype is *exactly* what I
proposed. Period. End of discussion.

and I totally agree with you here. You can serve any type of contentover Gemini, so what's all this fuss about? You have a strange use casewhere you need compression? Fine, you can do it. Good for you. Butplease don't waste our time by telling how much cool would be to changeevery browser just to read the usual 1-2K[1] pages.

Cheers,

Omar Polo

P.S.: I don't want to sound too harsh, in fact I have a local patch for gmid to allow the `entrypoint' config option inside `location' blocks, so that for instance one can do something like

server "xyz.com" { ... location "*.gmi.gz" { entrypoint "/my/gzip/script"; } }

to automatically generate gzipped files (using an hypotetical CGI script in /my/gzip/script) on the fly[2].

[0]: OK, not quite really, gemget/curl-like applications only implement the protocol, but I'm talking about more "user-facing" browsers.[1]: Stephane Bortzmeyer once shared with us the mean size of text/gemini pages as computed by lupa IIRC.[2]: actually, this will allow to generate *any* file on the fly, that's why I added it.