a space case for transparent gemtext compression

[Christian Seibold]

> 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.