approachabe & frugal & composable

[Sean Conner]

It was thus said that the Great solderpunk once stated:
> 
> In short, there was supposed to be a single, concrete "unit of
> interface" with narrow scope that a client author has to decide how to
> implement.  Variation between clients in how that was done would not
> substantially change the overall user experience.
> 
> With stuff like data:, feed:, tag:, geo:, and the myriad other
> "non-locational schemes", all of this goes out the window.  What is a
> client supposed to do with all these?  

  Web and gopher clients already face this issue.  Web browsers have solved
this issue by allowing the user to configure a program to handle an unknown
URI scheme.  I've registered the "gopher" with Firefox to go through a
gopher proxy, so I can't see why this can't be an option for Gemini clients. 
I'm not aware of a scheme like mailcap (for handing of MIME types) for URI
schemes, but even a simple:

	gopher:	my-gopher-client
	http:	firefox
	https:	firefox
	geo:	missile-launcher

will be good enough (and not even mandatory---I'm just throwing out an idea
here).

> If I want to write a minimal
> client that just knows how to follow gemini:// links and nothing else,
> what the heck do I do with a tag: link?  Display it to the user, or
> hide it?  

  As a quick solution, how about just display a page with:

	I don't know how to handle tag:conman.org,1998-10-16:site
	Sorry about that.

Done!  Ship it!

> If I choose to display it using exactly the same code path I
> would use to to display a gemini:// link, I need to go out of my way
> to make that code path robust against stuff that doesn't make sense for
> "proper" links, like there not being a "netloc" component (AV-98
> currently silently drops tag: links, for example, because they cause an
> Exception when I try to handle them as if they were a "proper" link).

  There exists code to parse a URI, whether homegrown or a library.  At the
very least, the client can check the scheme portion for "gemini".  I've
already seen URIs for http:, https:, mailto: and data: [1].

> If I *do* successfully display them as if they were a proper link and
> the user tries to follow one, what is supposed to happen?  Assuming I
> fix the aforementioned problem, AV-98 will say "Sorry, no support for
> tag", because it fills out a template that I designed thinking of cases
> like "Sorry, no suport for ftp", which most users will understand.  *I*
> would be very confused by a "no support for tag" message, I'd think
> "What, there *are* no tags in Gemini, what's going on here?".

  I've already mentioned Firefox, but Lynx gave me "Alert!: Unsupported URL
scheme!" when I tried using a gemini: link on a webpage.  Don't sweat it.

> So, I'm not sure how to proceed here.  People should feel free to
> experiment with possibilities, because informed decisions are better
> than uninformed ones.  But I would advise people not to get fiercely
> attached to any idea of how non-locational URLs might work in Gemini.
> It's uncharted territory.

  I think your concern (or fear) is overblown here.  Outside of

	http:
	https:
	mailto:

I think other URI types on the web will fall deep into the 0.56% of links
that aren't the above.

  -spc 

[1]	The Gemini Client Torture Test