💾 Archived View for rawtext.club › ~sloum › geminilist › 006730.gmi captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

-=-=-=-=-=-=-

<-- back to the mailing list

a space case for transparent gemtext compression

cage cage-dev at twistfold.it

Sat Jun 19 09:06:07 BST 2021

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

On Fri, Jun 18, 2021 at 08:22:32AM -0500, Christian Seibold wrote:

Hi!

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.

This is how bloated software starts.

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,

So are you arguing that gemini client should include a postscript orPDF interpreter? Supports HTML? JavaScript? There are libraries forthose in the most common languages.

which seems more like the approach Lagrange takes (Skyjake can
correct me if I'm wrong).

Please this is not the place to discuss a single implementation forgemini standard.

The fact is that or you are proposing a standard extension, and justlet me write that i am tired that about 60% of the traffic in thismailing list is about proposing extension to the protocol that stillneeds works to be finalized, instead of proposing fix (there is thegitlab repo for that). If you do not like gemini propose a newprotocol and i likely be the first to works on that if i think isgood. Or if this is not extension (and i disagree it is not, to beclear) it is a discussion about a single implementation which producenoise in this ml.

Moreover i think that promoting a "fat" client promotes clientmono culture as well. Complicated clients need more resources (peopleor money) and lead to monopolistic behaviour (even in good faith).

To be clear. No if lagrange implements X this does not means everyother client should follows the same path. In my opinion if animplementation follows the path you are proposing (bloating thesoftware) this, in my opinion, is a reason to not implements those(anti)features.

To reuse (badly) a metaphor that is used often these days, to me youare proposing tho transform an old boring tree that helps peoplemeditating with a shiny Christmas tree with colored light anddecoration which only purpose is to remember us to spend our money inthe commercial center nearby until it is disposed of, after theseason! :)

What, in my opinion, needs gemini now is not extension but fixing thestandard, new contents a lot of propaganda, i think help of everyoneis appreciated.

Bye!C.

PS: as usual, sorry for my bad English!