Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Gemini protocol seen by this HTTP client person

daniel.haxx.se

Post reply on HN
Print view View original

41–50 of 113 posts

Re: The Gemini protocol seen by this HTTP client person

#41

Post by giantrobot »

ertian wrote: post #28
Apreche wrote: post #7

Earlier quoted context omitted.

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.

Gemini doesn't support POST so no one can possibly pop in to say anything.

Re: The Gemini protocol seen by this HTTP client person

#42

Post by giantrobot »

progre wrote: post #11
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.

The problem with markdown, as I understand it, is that it's not possible to correctly render without reading the entire document. I think the gemini format is attempting to make it possible to basically render the document line by line.

If only HTTP could serve text/plain documents. If only!

Re: The Gemini protocol seen by this HTTP client person

#43

Post by lagniappe »

I'm from the telnet generation. It's sad that Gemini got so popular while underdelivering [0] or missing the mark in some areas. That makes me sad because even if a project came along to 'do things right', I don't even have the bandwidth to adopt another protocol I'll hardly use, and then invest the time to build content and gather links.

[0] - maybe underdelivering is the wrong word, but a mutual need was articulated and what was delivered was suboptimal

Re: The Gemini protocol seen by this HTTP client person

#44

Post by Karellen »

ilyt wrote: post #8
MatthiasPortzel wrote: post #4

> Gemini documents certainly are never visually very attractive 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…

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

> But why it isn't markdown? What does [Gemtext] add that markdown does not have?

I think that's the wrong question. Based on what I've read of Gemini, its focus is on simplification. The question the Gemini authors are interested in would be "What does Gemtext remove from Markdown?"

To which the most obvious answer, as you point out, is "HTML".

As for "Why not use markdown with the HTML elements taken out?" - does the world really need another markdown variant that's less capable than the current lowest common denominator?

I would argue it's actually a better idea to just call it a different format altogether, rather than attempting to fragment the markdown landscape even further. It also helps to forestall the question of "Why not add HTML support, like all other markdown renderers?" If adding HTML support is an anti-goal (which I believe it is) then making it so that adding that support requires someone to actually implement an HTML renderer puts up more of a barrier than leaving the door open for someone to just switch out the markdown engine for one that already does.

Re: The Gemini protocol seen by this HTTP client person

#45

Post by rhn_mk1 »

SoftTalker wrote: post #25
graypegg wrote: post #22

Earlier quoted context omitted.

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.

It will not. You'll lose line breaks.

Re: The Gemini protocol seen by this HTTP client person

#46

Post by Karellen »

SoftTalker wrote: post #25
graypegg wrote: post #22

Earlier quoted context omitted.

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.

You'll need to do a little bit more if you want paragraphs in your text, because otherwise HTML will just smush them together.

Re: The Gemini protocol seen by this HTTP client person

#47

Post by [deleted] »

ilyt wrote: post #8
MatthiasPortzel wrote: post #4

> Gemini documents certainly are never visually very attractive 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…

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

[deleted]

Re: The Gemini protocol seen by this HTTP client person

#48

Post by stonogo »

ilyt wrote: post #38
carapace wrote: post #24

Earlier quoted context omitted.

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

Alternative would need to fill similar function, while it can't even embed an image or put a table.

That's not what alternative means. A passenger train is an alternative to a bus, but you can't drive a train on a freeway. "Alternative" in no way implies "feature parity". Getting addicted to meth and dying in a shootout with the police is an alternative to completing a medical degree and retiring to the Poconos, but they do not fill similar functions.

Re: The Gemini protocol seen by this HTTP client person

#49

Post by layer8 »

Groxx wrote: post #20
MatthiasPortzel wrote: post #4

> Gemini documents certainly are never visually very attractive 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…

UTF-8: how does that view mesh with > This scheme is syntactically compatible with the generic URI syntax defined in RFC 3986 ^ that defines the percent encoding scheme. About the only way I can think of is if Gemini URLs are a superset, and don't need to use percent encoding... but that means ambiguity when someone hands you a percent-encoded URL. Did they mean %C5 or %C5 ?

Maybe they really mean IRIs (RFC 3987).

Re: The Gemini protocol seen by this HTTP client person

#50

Post by giantrobot »

ertian wrote: post #27
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 p…

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

To me Gemini looks like it was made by people that fetishized the idea of Gopher after reading about without ever have actually used it.

Gopher was not about reading documents, it was a way to map to resources. Those resources might be files or other servers. It was an improvement over FTP since gophermaps (menus) could be customized and link to servers rather than just files.

You could abuse information messages in a gophermap to make a readable document but it wasn't part of the RFC. You also had to make some terminal width assumptions because there wasn't a good way to control text reflow.

Gopher was interesting up until you used the web.

Post reply on HN