💾 Archived View for rawtext.club › ~sloum › geminilist › 005533.gmi captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
David Emerson d at nnix.com
Tue Feb 23 19:29:31 GMT 2021
- - - - - - - - - - - - - - - - - - -
Though I agree with the principle, and it would make a lot of sense in many larger projects, binding the protocol tightly to the content is appropriate at this scale and for this purpose. Unlike many projects which anticipate substantial sprawl, and welcome that effect, the Gemini spec aims to avoid becoming easily contaminated with features, an intentional constraint.
I'm no zealot here, but I do find the cleanliness and constraint refreshing.
At current the Gemini spec is dual-purpose, it describes the protocol,
and the text/gemini format.
Whilst gemtext is the "native" format for Gemini (as HTML is to HTTP),
one isn't required for the other to work, they are two distinct
things.
I think that they should be split into two specs, one for the protocol
and one for gemtext.
What would people think of this?
- Oliver Simmons (GoodClover)