Gopher urls around the internet tend to use a scheme in the form of
gopher://{host}:{port}/{type}/{selector}
(?{query}
is appended in the case of search results, though Gophie does handle this already). Entering these urls currently make Gophie send a selector called /1/
instead of
(none) or /
, bringing up a not found error on most hosts. Support for this form factor would be beneficial as it would be more compatible with the urls other clients use.
Also, at the moment (under Gophie 1.0) if I enter the URL gopher://gopher.somnolescent.net/aphrodisiac/aphrodisiac_-_01_this_nadir.wav
, it will (as far as I can tell) try to load it as a menu and hang up. This would be resolved without any guesswork on the client's end by supporting and using item types in the URL, like gopher://gopher.somnolescent.net/s/aphrodisiac/aphrodisiac_-_01_this_nadir.wav
(where s
is the type used for wave files). It could then show the download prompt depending on if the type is text-based or not.
(As for why URLs in the form of gopher://{host}:{port}/{selector}
aren't typically used, it's a matter of lessening the guesswork the client has to make. Not having the type in the URL itself would mean that I could have a file at gopher://example.com/file
and the client would not know whether it is a directory, text file, generic binary, image, etc.. With HTTP this is a nonissue, as headers and MIME types could be used to tell the client what it will be receiving, but in the case of Gopher which is a headerless protocol it would be left up to the client to try and figure out what kind of file it is, going against the philosophy of the intelligence being held by the server as in RFC 1436.)
I might've overwrote/overstated a bit but feel free to let me know if you have questions, since I'm really liking this client and it's looking to be one of the best current graphical ones I've used. Cheers!