💾 Archived View for rawtext.club › ~sloum › geminilist › 005581.gmi captured on 2021-11-30 at 19:37:34. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Oliver Simmons oliversimmo at gmail.com
Wed Feb 24 19:18:54 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Wed, 24 Feb 2021 at 19:07, John Cowan <cowan at ccil.org> wrote:
Part of the problem there is without a signal like "=: " that isn't likely to be ordinary content, it's easy to get confused. Consider this:
=====CUT HERE=====[...]
=====CUT HERE=====
It's obvious to a human that the last four lines are metadata and the rest is content. But a metadata processor's job is much simplified if the last four lines are:
[...]
That makes it clear that "Longaville", for example, is not a key. This is Lars's proposal. To it I add the convention that a link name beginning with =: contains metadata applicable to the linked resource. And that's it. I don't see that this is particularly more extensible than the "unmarked key-value pairs at the end" convention. As for readability, if we can get used to seeing "=
" as a link, we can get used to "=: " as metadata.
It appears you missed an important part of the key/value form: the toggle line.
A toggle line would be used (I suggested ^^^, but there may be abetter one), and it would be enable-only, there is no toggle off.(extra toggles must be ignored by clients)This enforces putting it at the end of a file, and prevents mixing itwith regular content, as being able to mix it would make Geminiawfully easy to extend.After the toggle the only acceptable lines would be either empty, or metadata.
Example:
/fooo Bar!^^^key: valueanother-key: another-value
Here was my original email where I explained how I thought it wouldwork very roughly:=
https://lists.orbitalfox.eu/archives/gemini/2021/005420.html