Re: Gemini link syntax update
2019-07-04 10pm
Solderpunk recently phlogged about current thoughts on the Gemini
protocol's potential link syntax:
TEXT 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:
TEXT No one to relate to 'cept the sea
Anyway, time to put the munchkin to bed. Have a good night
gopherspace...