Re: [gopher] New gopher proposal
Please don't cc me on replies; I get them from the list and it makes replying
to the list require unnecessary extra steps. See, I already replied to you
by accident at least once when I meant to reply to the list.
> > > Caps.txt looks like a way to make gopher client development a pita. If
> > > you want to use newer features you will have to send at least two re
> > > quests, of which one implies parsing an arbitrary file.
> >
> > Well, it's cacheable, at least, but your point is well-taken. Still, it
> > works "already."
>
> Of course, then there's the problem of gopher clients that /don't/
> understand caps files parsing them like a normal file. I'm assuming
> that it's served to the client but isn't shown to the user, so if it's
> purely a server thing then we might not have that problem. And if it's
> purely server-side, then wouldn't every caps-supporting client need to
> tell the server that it supports caps? If that's the case, it could
> cause problems for some server/client combination's. For example:
>
> Alice's gopher server provides a service which requires a caps file;
> Bob's client, which has caps support, connects to Alice's server but
> when Bob attempts to use Alice's service, it outputs an error. Why
> does it do that? Because, in Bob's user agent string, it doesn't tell
> the server that it can understand caps, so the server removes the
> caps-related data from the service's input, meaning the service can't
> understand its input, causing the error.
>
> I presume I've got some (or all) things wrong in the above example if
> I'm correct about the client needing to tell the server.
All features currently and in the future mediated by caps are supersets of
basic Gopher functionality. No one needs to implement caps to implement a
client. You only need caps to deal with certain conveniences the protocol
doesn't specify (and neither, for that matter, does Gopher+).
I think it's instructive to look at how a caps-enabled client would handle
such a request and how a caps-enabled client wouldn't. You could compare
OverbiteFF 3.0 beta versus 2.1, for example (or Lynx).
Caps enabled:
1. The client accesses the remote server just as a regular client would.
a. Functions that aren't caps-mediated just work "the same."
b. As a corollary, If the user requested gopher://x.invalid/0/caps.txt,
they get a text file, just like a regular client that doesn't know
about caps (assuming the file exists or is generated as a pseudoselector
by Gophernicus or Bucktooth), because the caps.txt fetch is requested
by the user, not internally by the client.
2. At some point the client needs to do a caps-mediated function, such as
break down the selector, query the server's metadata, etc.
a. If the caps data is already in the cache, it just "does it."
b. If it isn't, the client executes a fetch against selector "caps.txt".
i. If the first four characters are CAPS, it is parsed and stored.
ii. If it isn't, the client caches failure, usually with a default caps
that assumes no features.
c. The caps-mediated function is then done based on the result. If there is
a caps, for example, and it specifies a PathDelimeter (yes, I know this
is spelled wrong but it's too late now), then it can carve the path up
with it for "go up a level" or breadcrumb menus. Otherwise, the selector
is treated as opaque, as it would be by default.
Caps disabled:
1. The client accesses the remote server.
a. Basic Gopher functions, which are not caps-mediated, work "the same."
b. If the user requested gopher://x.invalid/0/caps.txt, they get a text
file, because the caps.txt fetch is just another fetch.
In both cases, part 1 (all base Gopher functions) work exactly the same. The
picture only changes when a caps-controlled function comes into play. Since
the non-caps client doesn't do any of that, it doesn't have to worry about it.
Notice: the server doesn't know, or care, that the client speaks caps. It's
just another selector. Anyone can ask for it. It just means something to the
caps-enabled client when the client itself fetches it for its metadata.
The criticism that two fetches are required is well-taken, but the fetch is
only needed when a caps-mediated function is to occur, and the caps spec
specifically provides for caching (which is only optional for the client to
implement, and is merely a request from the server to the client).
The whole idea is to implement something that's a superset of normal function,
that doesn't trip up existing clients, that is strictly optional, and that is
easy to implement in any existing server (as either a file or a
pseudoselector). It's not perfect, but it works.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@floodgap.com
-- Failure is not an option. It comes standard. -------------------------------
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
Reply to: