Re: Gemini link syntax update

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