Re: [gopher] A letter to Mozilla Foundation
Cameron Kaiser <spectre@floodgap.com> writes:
(On google chrome handling of gopher: URLs)
>> (There is also bug 30840, if people are told it's an unsupported
>> protocol and that they need another program to browse it, it's far
>> better than getting a google web search, no matter what is the
>> unsupported protocol.)
>>
>> http://code.google.com/p/chromium/issues/detail?id=30840
>
> I agree. It also makes it possible for an arbitrary extension to intercept
> the protocol instead of relying on the trick Overbite Chrome does, which is
> to notice that the user is going to a search page with a gopher URL in it
> and snatch control (the way the [refused] patch to that issue is written).
It is weirder than I first thought, if the url is inserted in the
address bar ("omnibox"), it does a web search, but clicking in a gopher
link in some web page does the expected thing (it asks for an external
viewer).
>> > I think anything helping to encourage its hierarchical nature serves to
>> > make it more distinct, and therefore more valuable/relevant.
>>
>> It's gopher's main strength. And at the same time, it's one of the
>> greatest weaknesses of the web. Some parts of the web are sometimes just
>> a big mess.
>
> One thing I really do want to work on, however, is something I've termed
> "reverse discoverability." Say you have a menu on host xx pointing to a
> terminal document like an item type 0 on host yy. You can't find out what
> other documents yy has in that directory reliably, though you can guess.
> IOW, you can't see the menu that the document on yy exists in, just that
> xx links to it.
>
> The initial start I'm looking at is to help people used to the web construct
> relative analyzable paths. While selectors are ultimately opaque, there are
> conventions. The reflex is to turn
>
> gopher://yy/0/menu/doc.txt
>
> into
>
> gopher://yy/0/menu/
>
> which doesn't work, it should be item type 1. I think we can pretty much
> reliably conclude that any selector ending in a slash on just about any sane
> filesystem means a directory, not a file, and Overbite should pop a requester
> suggesting to change the item type to 1 for them. Then they learn a bit about
> Gopher, and it's easy. Similarly, the trivial case of
>
> gopher://yy/0
>
> (or any itemtype other than 1) should just be automatically changed to 1.
> This doesn't handle the situation of
>
> gopher://yy/0/menu
>
> but I think we can agree that a priori we can't conclude what menu should
> be typed as. And plenty of text files have embedded tabs, so content sniffing
> wouldn't work. But this covers the common case.
>
> I'm open to ideas to making reverse discoverability possible, even if it
> requires a bit of server cooperation. What do you think?
On getting the parent menu, a problem is that there's no warranty that
there are "directories" and that they're separated by slashes. But I
think a convention could be established and that trying to "go up"
doesn't hurt (it could fail in some servers, but that wouldn't be
frequent (I think), and certainly not harmful (if there are no slashes,
it just gives the root URL)).
I recall some chat took place here some years ago, so I did some gmane
searching:
http://article.gmane.org/gmane.network.gopher.general/2332
http://article.gmane.org/gmane.network.gopher.general/2335
But I think a "go up" link which does this would be welcome (and useful)
in gopher clients. And, after all, the worst that might happen is
getting to the server root.
(And adding "go up" links to menus is also a good thing to do, so that
browsing is easy in any client. (And I still didn't do it on all menus
in my own gophersite...))
This would make it easier for people to move up without editing the URL,
but if they do that a warning is welcome. The best way would be adding a
warning to the error message, but there is no error message - using 0
will just show the menu as text.
A "were you expecting a menu" link could be placed on the XUL overlay or
as one of those messages that pop up at the top of the page. But I
wonder how to do that unobtrusively... it should at least have a "do not
show this later" option.
> Eventually Overbite will also put "return to root menu" XUL overlays even
> over terminal documents so that you at least have that, though the pure HTML
> approach right now is appealing because it's adaptable to those Mozilla
> browsers that lack XUL such as Camino and K-Meleon.
The overlay idea looks great.
If you're able to add HTML links to those documents, adding the link
there is a good workaround. (Or are they really just plain
text/images/..., instead of a HTML with that?)
>> Is there any J2ME gopher client? That'd make a good use for J2ME+GPRS
>> cell phones.
>
> There sure is! And I didn't even write it; I got contacted by somebody who
> really liked the concept of Overbite Android and wrote his own for his
> Nokia E51. It's a MIDlet; it should run on anything, even a Crackberry.
>
> http://felix.plesoianu.ro/index.php/page:Software:PocketGopher
It may run on my phone. I'll say something if I get the chance to test
it.
>> Thinking of Mozilla Suite and Gopher reminds me of this screenshot :-)
>>
>> gopher://gopher.quux.org/g/Software/Gopher/screenshots/mozilla.gif
>>
>> I'm sad I never used this, looks... interesting!
>
> I remember using it back in the day. My main objection to the way it worked
> was that it sorted selectors, which destroyed menus, and had no i
> itemtype.
I suppose it's just a XUL widget. Maybe changing the widget to support a
specified ordering does it, and I suppose it supports childless elements
(could be used for i items).
> But the tree metaphor was compelling, if unwieldy in massive menus.
It highlights the hierarchy :-)
> A really futuristic interface would allow this sort of thing in 2D rather
> than simply an expanding vertical tree. But that might be a little too alien
> for a web-addled world. :)
You mean "3D"? I must try gopherVR.
--
Nuno J. Silva
gopher://sdf-eu.org/1/users/njsg
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/gopher-project
Reply to: