[gopher] Clients, capabilities and discoverability

[Cameron Kaiser]

> > > 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 )

As I recall it looked something like

	[GOPHER$SOMETHING.SOMETHING.SOMETHING]THEFILE.TXT

which if my rusty VMS recollection serves me is roughly the same as a
standard Files-11 filespec.

> > 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).

caps would be optional to implement and fetch -- all it would do is add. If
caps were never accessed, a client would work just fine. I'm imagining caps
as a pseudo-selector to store server information that is cacheable and not
likely to change, so that a client that wanted that information could simply
cache it. And, yes, rather than being server generated, /caps could just be
literally a file named caps (although I would probably implement it as a
server-provided selector in Bucktooth).

Like I say, I envision people storing general information about the server
such as its location, a description, the server software (if desired), etc.,
and the path delimeter would be logically placed there as well. A client
would come along, fetch a file, and try to fetch the caps as well. It should
cache success or failure, and invalidate its cache after some period of time.
But a client that didn't know anything about caps would still work, and the
server doesn't have to be aware of caps either.

I can't really think of a downside to it, but beat away on it :)

> 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.

There are a number of MIDlet emulators out there, I think. I just run it
directly on my Android phone using Netmite.

> 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.

Something like that, although laid out in such a way that things weren't
overlaying other things. But it's more a pipe dream than anything serious :)

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- The world only beats a path to your door when you're in the bathroom. ------