a space case for transparent gemtext compression

[cage]

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 types
allow 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, Lagrange
doesn't take 4 user actions, it  takes 1. If other browsers don't have
this 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 full
gemini 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  about
compression, this is about pushing for complex client that could break
the 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 able
to explain where the problem is better than me.

Also i encourage  *everyone* that cares for gemini  (including you) to
helps to finalize the standard,  not advocating for re-implementing web
browser with an unfit protocol.

Bye!
C.