Re: [gopher] Clients, capabilities and discoverability
Cameron Kaiser <spectre@floodgap.com> writes:
>> 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
>
> Yeah, I remember that. That's why I don't want the client doing this
> kind of thing for the user (yet), because getting it wrong would be
> really bad and potentially leave the user in an unnavigable state. Most
> of the time it would work, but I don't want gopherspace restricted to
> Unix pathnames. After all, userserve.ucsd.edu (RIP) was an SE/30 using
> :-based Mac paths, and JumpJet was Windows using \es. There was even a
> VMS server or two for awhile.
What did it use? Dots? Or dots *and* a different path scheme? (According
to wikipedia, it seems that it's not like an unified file system and
that the file name is separated from the parent directory path,
http://en.wikipedia.org/wiki/Path_%28computing%29 )
> But if the user themselves tries to analyse the path and alter it, I
> think I should help them, unless people strongly object to this behaviour.
>
> What would be an interesting thought is a way for the server itself to
> tell the client about its capabilities. I'd fantasized about a special
> selector caps (or /caps, or 0/caps, etc.) that could have, say, key=value
> pairs telling the client about the server.
>
> CAPS
> Location=Yo mama
> PathDelimeter=/
> ServerSoftware=A snotty guy named Frank
This would be useful, not only for path separators, but also for other
enhancements. But I think this should be a long-term goal, it needs some
brainstorming - should we really make it so that acessing a resource
requires fetching two selectors? On the other hand, it's easier than
changing the server software (instead of coding /caps, one can write a
file with that name).
> Then, knowing how it can divide by path, it could even offer an entire
> breadcrumb menu. If it couldn't get the caps, then it would just offer a
> root menu. That could maybe go in an XUL status bar.
>> > 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.
>
> I would love to hear if it worked.
It will take some time, I'm still looking for a way to install
applications that does not involve a web download (it does bluetooth, it
just refuses to exchange .JARs over it).
Meanwhile, I will look for an emulator so that I can at least play with
the code.
>> > 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.
>
> Well, no. GopherVR actually is pretty obvious when you use it, and it's
> single menu per scene. The metaphor is, despite the concept, really not all
> that outlandish in practice. (I do need to fix how i itemtype causes it to
> spread the objects out everywhere; it makes V-2 searches nearly impossible
> to navigate.)
>
> When I mean a 2D interface, I mean one where the menus start sprawling out
> over a vast, "infinite" plane, allowing crosslinkages to be shown and the
> client window being essentially a window on a much larger scrolling workspace.
> But like I say, this would probably weird a lot of people out even though it
> would really make the hierarchy come alive.
One of such interfaces could be a graph, like this one (for the web)
http://upload.wikimedia.org/wikipedia/commons/b/b9/WorldWideWebAroundWikipedia.png
This really highlights hyperlinking, the (IMHO) main feature of both the
web and the gopherspace.
--
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: