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...