Sandra Snan sandra.snan at idiomdrottning.org
Mon Sep 28 07:35:08 BST 2020
- - - - - - - - - - - - - - - - - - -
Complexity inside the server I don't particularly fear.My biggest fear for Gemini has been a proliferation of protocols."Protocols" defined loosely, not just as foo:// but as whenever acomputer asks something of another and expects a reply in a particularformat.
That fear was behind my hesitiation re codifying behavior in the alttext strings earlier.
As for whatever a server does on its own, I leave great allowance.Requests being files in a file system or routes in an MVC. But when twocomputers talk to each other, that's the point when two giant spinningspheres of grinding greebles speeding through space need to makecontact. Need to get on the same page on what they are doing.
We'll look back years from now when gemspace collective standards have acomplexity that overshadows that of the W3C specifications, and maybewe'll recognize that this moment, this post was the Rubicon. Maybe we'llthink that the Pandora lid was already peeked through to the point of nosalvation, since an arbitrary sequence of GET requests could become aprotocol.
Even if the future disastrous level of complexity is inevitable, I'm notconvinced it needs to be parallel. When we are proposing protocols thatcould already be done through existing standards (such as https) I askthat there is very good reason why.
"Oh, it's chill, any particular client and any particular server can usethis for ANY semantics" only makes me more concerned, since it's thefoundation for a hundred hundreds of protocols.
I see how we want [comments, posting, uploading, interaction, talking]between the clients and the server. The equiv of "textarea" and dinkyli'l radio buttons, and POST requests are necessary for that. But whereare the fences? Slippery slope? More like abyss sans railing.
Sometimes there IS very good reason to scrap and start over. Tovoluntarily do a https://imgs.xkcd.com/comics/standards.png because youhave experience with possible use cases, good and bad, and you know howto implement a simpler, coherent solution to sit beside the palimpsestof wire hangers and chewing gum that preceded and inspired it.
Starting a new pile of junk next to the old pile of junk because you'vestarted having a hard time finding things in the old pile willultimately just leave you with two piles of junk.
The question raised by this isn't just "why Dioscuri?" It's "why shouldwe not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotzfor this problem?" That isn't rhetorical. There could be good answers. Ijust can't think of them.
The road to reckless complexity is spelled NIH with a ribbon bookmark.