| I think Gemini proponents who think Daniel is missing the point, or that he should not overthink this so much as it's just for fun, are the ones missing the point. Daniel is not saying that is a wrong thing. He is saying that he has a PR to review and would need a clearer spec for this and gives his opinion on how it can be improved. His opinion is interesting because he is a long time spec user and writer. One commenter says that it's like the coca cola boss criticizing a competitor, but curl implements a lot of protocols. He probably doesn't care. It's for fun, granted, but if you want curl to implement your fun project, part of the fun becomes doing things properly. If you bothered writing a spec, it might as well be unambiguous, no? Not that I think the point of Gemini is to be fun, mind you. I think it's a strongly political movement advocating for minimalism. I do believe it's a worthy cause. His point is also to criticize the technical choices but that's fair game too. Again, his opinions as someone who has a lot of experience in the field are interesting too. Should I implement such a protocol now, I would definitely get back to this article to make sure I'm paying attention to the right things and making the right tradeoffs for my use case. I overall think the Gemini community should take Daniel's input as a good contribution to their ecosystem. He took time to sit down and consider Gemini seriously. Several times. Now he finds gemtext pages ugly, it's his opinion expressed on his personal blog, it's not particularly interesting and this opinion is not particularly related to his expertise. It's also not worth discussing with logical arguments since it's taste. Now there's still a point that can be made from this: if many people find Gemini ugly, including someone used to deal with RFCs daily, that means it will stay small. And that it's in the end, not an adequate answer for widespread minimalism it could have been and which is a goal that seems worth pursuing. |
Sure, people want unambiguous specs. However there is a list of literally dozens of working clients, servers, and libraries that were implemented based on the Gemini spec as is. Perhaps Daniels concerns are, in practice, not as important?
https://github.com/kr1sp1n/awesome-gemini#clients
I would also point out the hell that is the HTTP/1.0 and HTTP/1.1 specs, and that it took ~15 years for the HTTPbis group to remove all the contrary and ambiguous parts of it. This had little impact on the raise of HTTP
> His point is also to criticize the technical choices but that's fair game too.
Sure, but many of his criticisms are false. Full Stop. (servers and clients DO support TLS resumption. Proxying does work and there are multiple working examples, client's do server certificate validation)
Or don't make sense ("Gemini closes a TLS connection after each request? HTTP figured out keeps-alives in 1996! This is bad design." HTTP has different access patterns. If Gemini had those access patterns it would be bad design. It doesn't)