Christian Seibold krixano at mailbox.org
Fri Jun 18 14:22:32 BST 2021
- - - - - - - - - - - - - - - - - - -
I think people would probably want either a different compression, or to just compress one file instead of a whole bunch of files. So we'd probably need to come up with a different format for compression of just single files. And this is actually *easier* to support than supporting zips, etc, because those are more like compressed directories that you can navigate within.
Anyways, for people wondering about the gempub project, it's the equivalent of both epubs, but with gemtest, and also has the goal of being used for gemini capsule archives. The spec for gempubs is here, if anyone wants to contribute. You can perhaps suggest this to other browsers to support: https://codeberg.org/oppenlab/gempub
I do want to note that the gemini protocol doesn't care about what's send over it. This is why mimetypes were added to the protocol. You can send any binary data over gemini. This is why compression doesn't need to be in the main protocol - because you can send over the compressed stuff just as any other binary file can. It's the job of the gemini browser to handle the compressed data by reading the mimetype and dealing with that mimetype in some way. And if it's too complicated, then tell your browser maintainer and they can fix it if they want. If they don't want to, then I would consider looking into other gemini browsers that do support what you want.
Finally, the other consideration is whether supporting this within clients adds too much complexity. Personally, I do not think so, as there are tons of very simple libraries you can use for supporting compression. Golang even has these in its standard library.
Some gemini browser maintainers are probably going to argue that it's not the purpose of a browser to support opening zips, as a similar argument has been used for Gemini Subscription Feeds, Atom Feeds, audio/video files, and other such things. I would have to completely disagree. The point of a browser is to browse documents - that's the scope of gemini browsers.
I do recognize that there are, however, two different approaches to this. Have the "gemini browser" be a full document browser for the gemini protocol, or have it just deal with the gemini protocol and pass the documents off to another program. The problem, of course, is many applications don't support gemini links, which is definitely why I prefer the 1st approach, which seems more like the approach Lagrange takes (Skyjake can correct me if I'm wrong). The point is, the point of a browser is to browse geminispace. Which means you need to either support things yourself, or have the ability to pass them off to another application that *can* support them properly.