The Gemini protocol seen by this HTTP client person • Hacker News Board

Re: The Gemini protocol seen by this HTTP client person

#21

Post by graypegg » Sun, May 28, 2023, 5:04 PM UTC

zimpenfish wrote: post #16

ilyt wrote: post #8

Earlier quoted context omitted.

> As a proponent of the Gemini protocol, I take issue with this line. The Gemtext format is a minimal markup format for text documents. It's a way of semantically indicating "this part is plaintext", "this part is a link", "this part is a header". Unlike HTML/CSS, it does not provide a mechanism for the author to style their documents. Instead, it is up to the client to render the text document, however the client ch…

> What does it add that markdown does not have ? "a satisfactory rendering can be achieved with a single pass of a document, processing each line independently" - from what I understand of Markdown parsing, it's a lot more complex than this because of the spec. > There appears to not even be a support for a basic table Given the number of Markdown table attempts I've seen over the years, I don't blame them for wantin…

Gemtext has the pre formatted text fence that it specs as a mode-switch. Is that impossible with markdown? I think you could probably design every control symbol in markdown as a switch to “bold mode”, or “link content mode” and leave it at that. State machine style I guess?

Re: The Gemini protocol seen by this HTTP client person

#22

Post by graypegg » Sun, May 28, 2023, 5:07 PM UTC

SoftTalker wrote: post #19

graypegg wrote: post #10

Earlier quoted context omitted.

Gemtext is weird, it’s hyper-focused on a very specific form of text publishing. It’s not trying to be “old internet” featuring the creative freedom of its users, it’s just text content and that’s it. Not even inline links or images! Which I personally think makes it a bad format for the old-internet mainstay of “website about one specific interest of mine”. I run a little capsule but I find myself with not much to d…

Gemtext seems to be more like wanting to be an online typewriter. Back when typewriters were used to write documents, there was one typeface and font, and no hyperlinks or images. To reference other documents you could use footnotes or a bibliography. Margins and line spacing (except maybe for block-quotes) were fixed. A lot of useful information was communicated in this format, but it does seem a bit too austere tod…

That’s a good analogy, that does seem to be the guiding aesthetic they’re going for.

It’s austere but I can see why people like it if they’re really into writing as this raw “doesn’t need anything else” medium. I like my silly little pictures and syntax highlighted code samples though.

Re: The Gemini protocol seen by this HTTP client person

#23

Post by carapace » Sun, May 28, 2023, 5:08 PM UTC

majkinetor wrote: post #6

Markdown is way better IMO, also very simple yet allowing for better visuals and more expressivness, and new protocol should be designed to use it as its text format.

Markdown is, uh, not so good, it just won a popularity cintest. E.g. Creole is much better. https://en.wikipedia.org/wiki/Creole_(markup)

Re: The Gemini protocol seen by this HTTP client person

#24

Post by carapace » Sun, May 28, 2023, 5:15 PM UTC

spenczar5 wrote: post #3

The high-level criticism, which is that Gemini's specification is too loose and vague, seems very, very convincing, even if the specifics aren't. In a subtle way, this is a significant hurdle for any competitors to the HTTP world. They have to overcome 30 years of technical debate and refinement as ambiguities have been hammered down.

Gemini isn't a competitor to HTML, it's an alternative.

Re: The Gemini protocol seen by this HTTP client person

#25

Post by SoftTalker » Sun, May 28, 2023, 5:18 PM UTC

graypegg wrote: post #22

SoftTalker wrote: post #19

Earlier quoted context omitted.

Gemtext seems to be more like wanting to be an online typewriter. Back when typewriters were used to write documents, there was one typeface and font, and no hyperlinks or images. To reference other documents you could use footnotes or a bibliography. Margins and line spacing (except maybe for block-quotes) were fixed. A lot of useful information was communicated in this format, but it does seem a bit too austere tod…

That’s a good analogy, that does seem to be the guiding aesthetic they’re going for. It’s austere but I can see why people like it if they’re really into writing as this raw “doesn’t need anything else” medium. I like my silly little pictures and syntax highlighted code samples though.

The weird thing is you can write like that in HTML if you want to.

    
      Lots of plain text

Will render just fine. I don't think any browsers really even require those opening and closing tags.

Re: The Gemini protocol seen by this HTTP client person

#26

Post by sshine » Sun, May 28, 2023, 5:23 PM UTC

carapace wrote: post #23

majkinetor wrote: post #6

Markdown is way better IMO, also very simple yet allowing for better visuals and more expressivness, and new protocol should be designed to use it as its text format.

Markdown is, uh, not so good, it just won a popularity cintest. E.g. Creole is much better. https://en.wikipedia.org/wiki/Creole_(markup)

Why is Creole better?

To me they look much the same.

Except I prefer Markdown for the looks and how widespread it is.

I was a Wikipedia contributor for many years before Markdown came along, and I think Markdown has a better flavor for hyperlinks. "[link text](url)", "[link text][footnote] + [footnote]: url" are just great. I write like this even without any expectation of rendering it as anything but plaintext.

Re: The Gemini protocol seen by this HTTP client person

#27

Post by ertian » Sun, May 28, 2023, 5:25 PM UTC

ilyt wrote: post #9

This protocol looks like someone didn't exactly know how HTTP worked, and more importantly, from where the bloat came from, then tried to do something too simple. Then went on not understanding why people value Markdown, and do something entirely worse, without any good reason.

I think you just misunderstand the point. A lot of criticism of Gemini seems to make the assumption that it's intended to replace HTTP and that it's badly thought through for that use. In fact, I think it basically came from a niche group of Gopher hobbyist users who wanted to fix a few longstanding annoyances with Gopher. They wanted something that anybody could write a client or server for as a fun little weekend project, not something that requires end-to-end 3rd-party-verified proxiable SSL security.

Re: The Gemini protocol seen by this HTTP client person

#28

Post by ertian » Sun, May 28, 2023, 5:31 PM UTC

Apreche wrote: post #7

spenczar5 wrote: post #3

The high-level criticism, which is that Gemini's specification is too loose and vague, seems very, very convincing, even if the specifics aren't. In a subtle way, this is a significant hurdle for any competitors to the HTTP world. They have to overcome 30 years of technical debate and refinement as ambiguities have been hammered down.

I agree. I think a lot of the problem can be solved with discipline rather than a new spec entirely. If HTTP offers features that are offensive or unwanted, simply don't use those features. Make an HTTP server and client that only implement a subset of HTTP. Then use a subset of HTML, or another content type entirely. This means anyone still using a popular browser like Chrome can visit your sites, but people using a…

> This means anyone still using a popular browser like Chrome can visit your sites

I think this would be seen as more of a drawback than a feature. If you're trying to build a tight-knit little hobbyist community, random people popping in and complaining that "these pages are boring, where are all the images?!" isn't helpful.

Re: The Gemini protocol seen by this HTTP client person

#29

Post by majkinetor » Sun, May 28, 2023, 5:43 PM UTC

derekzhouzhen wrote: post #15

majkinetor wrote: post #6

Markdown is way better IMO, also very simple yet allowing for better visuals and more expressivness, and new protocol should be designed to use it as its text format.

No, Markdown is a format for authoring HTML. It makes a very bad interchange format because the it leaves too much ambiguity in parsing. Also, parsing speed of Markdown is much slower than the parsing speed of a strictly conforming XML file.

That is all easily solvable.

Parsing speed, really? In this age?

It has its problems but its easy, widely adopted, with hundreds of tools, and simply way more capable than gemtext (which is simply very bad).

Re: The Gemini protocol seen by this HTTP client person

#30

Post by zimpenfish » Sun, May 28, 2023, 5:44 PM UTC

graypegg wrote: post #21

zimpenfish wrote: post #16

Earlier quoted context omitted.

> What does it add that markdown does not have ? "a satisfactory rendering can be achieved with a single pass of a document, processing each line independently" - from what I understand of Markdown parsing, it's a lot more complex than this because of the spec. > There appears to not even be a support for a basic table Given the number of Markdown table attempts I've seen over the years, I don't blame them for wantin…

Gemtext has the pre formatted text fence that it specs as a mode-switch. Is that impossible with markdown? I think you could probably design every control symbol in markdown as a switch to “bold mode”, or “link content mode” and leave it at that. State machine style I guess?

> Is that impossible with markdown?

No, that bit is the simple bit.

> you could probably design every control symbol in markdown as a switch

You need a layered mode though - you can have bold, italic, monospaced, header and link all active at the same time - which means you've got 32 states right there. But also! If you do something like `# Header _*bold-italic`, that italic and bold don't apply because the EOL stops the header state and retroactively cancels those bold-italic attributes. But on a non-header line, `_*bold-italic\nstill bold-italic*_` works fine because EOL doesn't cancel them. But also also! If you mismatch the order, it won't match both. Or, at least in Marked 2, if you mismatch the order on both sides of a non-attributed word, that word will get the wrong styling (`_*with mismatched_* middle *_attributes*_`).

In summary, Markdown parsing is a clusterfuck.