💾 Archived View for gemi.dev › gemini-mailing-list › 000745.gmi captured on 2024-08-19 at 01:54:49. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
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)
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) > >
On 2021-02-23 05:21PM, Oliver Simmons wrote: > At current the Gemini spec is dual-purpose, it describes the protocol, > and the text/gemini format. The current spec, while it is the "formal" spec, is intended to be rather informal (compared to other specs), and I suppose it was just easier to group them together at the time. > 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. Something that should be emphasized more IMO, since people don't seem to understand this every time they suggest to add inline markup. > I think that they should be split into two specs, one for the protocol > and one for gemtext. I'm sure if Solderpunk ever pursues submitting it as a formal RFC (something that he was contemplating, but wanted to wait until the final spec freeze) then the IETF would help us formalize it and organize it more coherently. Using my knowledge of how RFCs are structured I'm fairly sure they would both be in one RFC but separated meaningfully. The current spec has gemtext separated, but the distinction could be made more clear. -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210223/d184 f6ef/attachment-0001.sig>
Le mardi 23 f?vrier 2021, 18:21:47 CET Oliver Simmons a ?crit : > 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. This is on the roadmap as I understand it, when converting the specification to RFCs it will be split into two RFCs. But I cannot find where I read that anymore, so maybe I?m not remembering correctly? C?me
On Tue, 23 Feb 2021 at 19:29, David Emerson <d at nnix.com> wrote: > > 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. > The protocol and content aren't bound tightly in any way, Gemtext is the default and is in the same document, that's all. Splitting the documents wouldn't change anything, and I don't want anything to change as Gemtext is really nice, I just thought it would make sense to have them split.
On Tue, Feb 23, 2021 at 2:29 PM David Emerson <d at nnix.com> wrote:
> 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.
I think that makes sense for Gopher, but not for Gemini. As we saw a day
or two ago, Gemini servers are designed to serve many files that are not
text/gemini, and are actually doing so. Indeed, there is no reason that an
HTTP server can't serve text/gemini as well, and hopefully an HTTP proxy
will recognize text/gemini content and pass it through unchanged.
I feel pretty confident that the IETF will want them to be split.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
Almost all theorems are true, but almost all proofs have bugs.
--Paul Pedersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210223/a8dc
c6c2/attachment-0001.htm>
On Tue, Feb 23, 2021 at 09:07:32PM +0100, C?me Chilliet <come at chilliet.eu> wrote a message of 18 lines which said: > This is on the roadmap as I understand it, when converting the > specification to RFCs it will be split into two RFCs. AFAIK, there is no published and "official" roadmap, just ideas on the mailing list and may be a folder with files, in Solderpunk's home directory. > But I cannot find where I read that anymore, so maybe I?m not remembering correctly? This is one of the weaknesses of Gemini, there is no visibility on what is "work in progress".
On 24 feb. 2021 at 13:26, Stephane Bortzmeyer <stephane at sources.org> wrote: > On Tue, Feb 23, 2021 at 09:07:32PM +0100, > C?me Chilliet <come at chilliet.eu> wrote > a message of 18 lines which said: > > This is on the roadmap as I understand it, when converting the > > specification to RFCs it will be split into two RFCs. > AFAIK, there is no published and "official" roadmap, just ideas on the > mailing list and may be a folder with files, in Solderpunk's home directory. gemini://gemini.circumlunar.space/docs/faq.gmi Section 4 "Contributing to the Gemini project" should have a new subsection "Roadmap". It would probably list the 3 month spec freeze we had during spring last year and the (after the fact) deadline we had for non-trivial changes when we were supposed to go into a 6 month spec freeze in the early summer. -- Katarina -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210224/78c7 212f/attachment.htm>
Apparently, I sent this only to Oliver Simmons and not to the list. On Tuesday, February 23, 2021 7:07 PM, Katarina Eriksson <gmym at coopdot.com> wrote: > Oliver Simmons <oliversimmo at gmail.com> wrote: > > > 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) > > Here's a thread about it from May last year: > gemini://gemi.dev/gemini-mailing-list/messages/001037.gmi > > It resulted in some rearranging of the order it appeared in the specification. > > Solderpunk's thoughts about it: > gemini://gemi.dev/gemini-mailing-list/messages/001070.gmi > > Personally, I don't have strong opinion one way or the other. > > --? > Katarina
> On Mar 1, 2021, at 13:02, Katarina Eriksson <gmym at coopdot.com> wrote: > > Apparently, I sent this only to Oliver Simmons and not to the list. Previously in a theater near you... Reply-To mailing list? gemini://gemi.dev/gemini-mailing-list/messages/003781.gmi ?0?
---