💾 Archived View for rawtext.club › ~sloum › geminilist › 006731.gmi captured on 2024-02-05 at 10:56:40. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Christian Seibold krixano at mailbox.org
Sat Jun 19 09:42:26 BST 2021
- - - - - - - - - - - - - - - - - - -
This is how bloated software starts.
Who says what is bloated? How much features do we have to add for something to be bloated? Was adding TLS bloat? TLS added a bunch of complexity to the protocol. What about gemtext? Is gemtext bloat?
This isn't black and white. Bloat is a ratio of various things, including complexity added, size added, and performance effects vs. how much the feature adds to the program and its usefulness - it's "power to weight ratio"
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 or
PDF interpreter? Supports HTML? JavaScript? There are libraries for
those in the most common languages.
Nope, I never suggested such a thing. HTML isn't used in geminispace. Neither is javascript. Additionally, again, you have to look at the pros and cons of things. Javascript adds significant performance and security problems. Compression **doesn't**.Stop trying to compare compression to Javascript and HTML, especially when compression is very basic and doesn't add barely any LOC or performance decreases.
Let's look at an lz4 library:https://github.com/lz4/lz4
It's 49000 MB/s on a Core i7-9700K CPU @ 4.9GHz.And it's 5699 LOC.
Btw, this is the approach that Solderpunk used to determine what should go into the protocol. It's right on the front page of the gemini capsule:"Strives for maximum power to weight ratio"
Imo, compression fits perfectly with this. Some people will disagree, and that's fine. That's not gonna change my opinion on this matter though. All I ask is that you stop using personal attacks, because it doesn't help your argument.
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 for
gemini standard.
Yes it is. The OP was asking for a specific feature, and I suggested a client that had that feature that they can use. I NEVER suggested every single client should implement compression, and I actually said the opposite:"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."
Passing things off to other applications is just as valid of a way to deal with this, and it's what AV-98 and various other clients do.
The fact is that or you are proposing a standard extension, and just
let me write that i am tired that about 60% of the traffic in this
mailing list is about proposing extension to the protocol that still
needs works to be finalized, instead of proposing fix (there is the
gitlab repo for that). If you do not like gemini propose a new
protocol and i likely be the first to works on that if i think is
good. Or if this is not extension (and i disagree it is not, to be
clear) it is a discussion about a single implementation which produce
noise in this ml.
I in no way proposed an extension to the protocol. In fact, I proposed the exact opposite, that this should stay *out* of the protocol, and be in client applications for people who want to support this:"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."
Moreover i think that promoting a "fat" client promotes client
mono culture as well. Complicated clients need more resources (people
or money) and lead to monopolistic behaviour (even in good faith).
People are smart enough to decide for themselves what client they want to use. I'm allowed to promote a client. I think it's very presumptuous to think I'm somehow "propagandizing" people into supporting Lagrange. It's ridiculous. People are smart enough to decide for themselves what client they want to use.
To be clear. No if lagrange implements X this does not means every
other client should follows the same path. In my opinion if an
implementation follows the path you are proposing (bloating the
software) this, in my opinion, is a reason to not implements those
(anti)features.
I didn't suggest any such thing, as I've already said above.