💾 Archived View for rawtext.club › ~sloum › geminilist › 006736.gmi captured on 2023-11-14 at 09:08:21. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
cage cage-dev at twistfold.it
Sat Jun 19 10:55:59 BST 2021
- - - - - - - - - - - - - - - - - - -
On Sat, Jun 19, 2021 at 03:42:26AM -0500, Christian Seibold wrote:
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?
There are reasons why TLS is in gemini and compression not, please reread the FAQ.
This isn't black and white.
I agree it is not.
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"
I agree.
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.
It is, because as you correctly said, the protocol with mime typesallow for any type of document.
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**.
So are you OK, with PDF and postscript that you left out?
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.
You you know that compression "barely" add a few effort for every possible programming scenario?
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"
Yes, please reread the FAQ. Compression is not in the standard for reasons.
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.
You tell me that i am presumptuous and accuse me for personal attacks?
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."
I quote another your message:
"Please read my own response again. If you're using zips, Lagrangedoesn't take 4 user actions, it takes 1. If other browsers don't havethis functionality, then tell them. Browsers should implement this,not the protocol. It's that's simple."
And a few lines above: "...why I prefer the 1st approach" [a fullgemini document browser].
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.
But you prefer a full gemini browser, right? And clients *should*implement a form of decompression one way or another, right?
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.
i like lagrange a lot, this is neither about lagrange nor aboutcompression, this is about pushing for complex client that could breakthe geminispace.
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.
And i can requote your other message as above.
Please reread the Bortzmeyer reply, he is wiser than me and so is ableto explain where the problem is better than me.
Also i encourage *everyone* that cares for gemini (including you) tohelps to finalize the standard, not advocating for re-implementing webbrowser with an unfit protocol.
Bye!C.