Re: Gemini link syntax update | |
2019-07-04 10pm | |
Solderpunk recently phlogged about current thoughts on the Gemini | |
protocol's potential link syntax: | |
Quick update on link syntax | |
I was a big initial supporter of the "magic string" syntax (and | |
in particular => as the specific magic string... it looks like an | |
arrow and as such looks like what it does: points somwhere). I | |
remain a big supporter of this strategy. | |
I do not have any concern over using what solderpunk/visiblink | |
refered to as angle brackets (but I assume to mean greater than | |
or less than). I feel like people are VERY used to html. Heck, | |
my Mom has copied in some basic html for stuff online and she | |
doesn't even understand what I mean when I ask her "well, what | |
folder did you save the photos in?". As such, I remain steadfast | |
that => seems solid. I also like -> fine. I think either of | |
those are fairly unlikely to come up in an actual url. As a | |
result, the need for escaping may be there, but is mostly | |
unlikely in practice. | |
Some very good questions have been brought up though: | |
1. If we use => should there be a space after it before the | |
text/link? If so, is it mandatory? If so, what exactly | |
constitutes a space? | |
I am in favor of making the space optional and trimming | |
any whitespace characters (other than newline which I | |
think would result in a broken link) from the beginning | |
and ending of the remaining string. | |
line = "=> \t gemini://test.com A link" | |
line = line[2:].trimWhitespace() | |
My basic thoughts in code that does not belong to a | |
particualr language (but resembles python or go). | |
At that point the string could be split to get a | |
link and its text. | |
2. URL first or link text first? | |
I am kind of split on this one. I think my preference | |
is to do url first. For the simple reason that it will | |
be just slightly easier to parse the line in any | |
language that lacks a last index of function. | |
I would definitely not categorize my opinion on that | |
as strong. I am mostly good either way. It is much | |
less of a big deal to me than how question #1 above | |
gets sorted out. | |
3. URL escaping. | |
The subject of escaping characters in URLs has not been | |
brought up, to my knowledge at least. Because there is the | |
intention of parsing on a space after, or before...depending on | |
the answer to #2, the URL... the url cannot contain any spaces. | |
Will we be using %20 to denote a space? Will we take on some | |
other convention? Are there other characters that will we | |
need to represent in an alternate form? | |
I do not know the answers to the above, but do think that | |
they should be addressed. I definitely have no trouble | |
using spaces and tabs in gopher addresses... Web addresses | |
on the other hand are generally URL encoded. If we are going | |
to use space as a delimiter for our link lines I absolutely | |
think we need to, at the very least, do some kind of | |
encoding of spaces within URLs and both clients and servers | |
need tos tandardize on the same encoding. | |
The alternative is to parse by space, but allow spaces in | |
filenames... which is madness. I also do not think it is | |
within the realm of possibility that just asking people not | |
to put spaces in filenames is going to happen... if it was | |
going to happen it already would have happened everywhere | |
else (I maintain it is a terrible idea to put a space in a | |
filename). | |
Shout out to this phlog for their thoughts on the matter as well: | |
No one to relate to 'cept the sea | |
Anyway, time to put the munchkin to bed. Have a good night | |
gopherspace... | |