From an implementor's view I decided to not implement Gemini as it is specified, because I do not like its text/gemini default format.
They should either decide for a specified full file format, e.g. CommonMark or HTML5 (with index.html as default routes) or don't try to implement a file format inside a network protocol at all.
In my opinion, file structures (and layouts thereof) should have nothing to do with a network protocol.
The reason why the web exploded was because HTML was the best technology to allow custom web pages, and more importantly, while in parallel to allow them to interlink. If either of these two aspects are separated, the concept won't work for the discovery and exploration of new content.
Remember the sparkling unicorn gifs and construction animations everywhere? That's what the web was about.
I do not agree with how JS has exploded over the years, hence the reason for writing my own web browser/scraper/proxy [1] - but I do agree with the "why" HTML5/CSS3 makes sense for themselves while ignoring the scriptable aspects.
For me, as someone trying to build a web browser, the text/gemini concept makes it super-hacky and very much prone to future errors to integrate it with the rest of the web. Faking and rendering another file format (based on the runtime environment) should not be its recommendation.
A much simpler approach would be e.g. simply using "gemini://" for resources inside an HTML(5) file.
Additionally, a killer feature for HTTP/1.1 is the continuous download of files that have been partially downloaded. While I think the practical implementation of 206 ranges is pretty messed up (looking at you, nginx, who cannot count the amount of ranges requested), I do agree with the positive aspects of it.
Something like this has to be integrated into a minimal network protocol, otherwise it cannot be adopted in mobile/2G slow areas.
Gopher lost to HTML because Gopher was TUI-oriented when HTML was GUI-oriented. And Gopher lost a second time when Web 2.0 (JS expansion) occurred.
TUI is not so vastly inferior to GUI - at least when it comes to reading and writing and sparse multimedia contents. The Web exploded because GUI appears to be more user-friendly. There are vastly more users that need "friendliness" than users that just need honesty ;-)
In my mind, if one wants to suggest an alternative to the Web, one either has to go back to the passive, text-oriented web or one-up the current Web with something even more interactive and even more graphical.
In my opinion the only way to achieve successfully the latter is to provide a much easier way to make remote interactive graphical applications, with strong security guarantees of course. I believe that something like Squeak could do that job. It kind of already was done with Croquet/Cobalt.
As for the former approach, I would suggest 80 columns monospace text as the standard document format, with the footnote-style convention for links - not some oddity that's midway between text and HTML.
So in both case I think one has to be extreme in order to succeed. Either extreme sophistication or extreme simplicity.
Having been involved in the VERY LONG conversation re: markup for gemini I can say there were a lot of considerations. There was definitely talk about whether a format fit into the protocol at all. The text/gemini format was landed on as a simple way to have baseline text linkages that all clients would recognize. It has the added benefit of being simple to write, simple to read, simple to parse.
Because servers send mime-types in their response there is literally nothing stopping a client from implementing a full html rendering engine, a markdown rendering system etc. for when they receive documents of those types.
I agree on the own text format. It just seems needlessly complicated without really offering benefits.
The argument of focusing on text over styling is a fair one, but it would also have been easy to only support a subset of HTML/CSS.
If one has to create a new format for Hypertext, it should however do more than HTML does and really innovate on the concept. That would have been interesting, to make it for example more semantically structured and thus open new possibilities or include ideas from other Hypertext projects like Xanadu.
As it stands, I would prefer markdown or just plain html as well.
They should either decide for a specified full file format, e.g. CommonMark or HTML5 (with index.html as default routes) or don't try to implement a file format inside a network protocol at all.
In my opinion, file structures (and layouts thereof) should have nothing to do with a network protocol.
The reason why the web exploded was because HTML was the best technology to allow custom web pages, and more importantly, while in parallel to allow them to interlink. If either of these two aspects are separated, the concept won't work for the discovery and exploration of new content.
Remember the sparkling unicorn gifs and construction animations everywhere? That's what the web was about.
I do not agree with how JS has exploded over the years, hence the reason for writing my own web browser/scraper/proxy [1] - but I do agree with the "why" HTML5/CSS3 makes sense for themselves while ignoring the scriptable aspects.
For me, as someone trying to build a web browser, the text/gemini concept makes it super-hacky and very much prone to future errors to integrate it with the rest of the web. Faking and rendering another file format (based on the runtime environment) should not be its recommendation.
A much simpler approach would be e.g. simply using "gemini://" for resources inside an HTML(5) file.
Additionally, a killer feature for HTTP/1.1 is the continuous download of files that have been partially downloaded. While I think the practical implementation of 206 ranges is pretty messed up (looking at you, nginx, who cannot count the amount of ranges requested), I do agree with the positive aspects of it.
Something like this has to be integrated into a minimal network protocol, otherwise it cannot be adopted in mobile/2G slow areas.
[1] https://github.com/cookiengineer/stealth