Re: [gopher] A letter to Mozilla Foundation
Do try GopherVR, you won't be disappointed. I've vgot it running on
my iMac and I'm very happy with it.
On 4 August 2010 15:52, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote:
> 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
>
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/gopher-project
Reply to: