# Re: gopher+ support in the URL draft.

Dirk Herr-Hoyman (hoymand@joe.uwex.edu)
Tue, 8 Mar 94 08:52:42 -0600

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mark P. McCahill: "Re: gopher+ support in the URL draft."
- Previous message: Mark P. McCahill: "gopher+ support in the URL draft."
- Maybe in reply to: Mark P. McCahill: "gopher+ support in the URL draft."
- Next in thread: Mark P. McCahill: "Re: gopher+ support in the URL draft."

    Date: Tue, 8 Mar 94 08:52:42 -0600

    Message-Id: <9403081452.AA26689@joe.uwex.edu>

    To: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>, timbl@www3.cern.ch

    From: hoymand@joe.uwex.edu (Dirk Herr-Hoyman)

    Subject: Re: gopher+ support in the URL draft.

At 7:17 PM 3/7/94 -0600, Mark P. McCahill wrote:

>With a minor change to the syntax of the current gopher URL, we can have both
>plain old gopher and gopher+ in the same URL and have a nice regular syntax.
>The improved syntax is basically the current gopher URL syntax, but uses an
>encoded <tab> character as a seperator rather than the <?> character. Using
><tab> as a seperator is convenient because <tab> cannot occur in gopher
>selector strings. The only time the <?> is used in the current gopher selector
>is when the URL points to a gopher search engine and is passing the search
>engine a search string (tth of words for which to search)... the virtue of
>having a regular syntax and using a seperator character that cannor occur in
>gopher selector strings should to be obvious.
>The format of a gopher URL is:
>

Mark, I'm not following why you are changing from using ? as the seperator
for searches to tab. It seems that if you let %09 be the gopher+ "flag"
you could still use ? for searches. Perhaps I'm just being dense here and
you can educate me. I've listed some counter examples that appear to work
for me.

>An example of a URL pointing to a gopher type 7 item (a search engine)
>where the string foobar is to be submitted to the search engine is:
>
> gopher://host [port]/7a_gopher_selector%09foobar
>
gopher://host [port]/7a_gopher_selector?foobar

If this were a 7+ search, then

gopher://host [port]/7a_gopher_selector%09?foobar

Which looks to both preserve the existing search syntax and allow for gopher+.

I would prefer to see an orthagonal treatment of searches (and anything
else) within the not-so-opaque selector string. Are we going to allow for
a separate evolution of these "added" parts of the selector strings by each
service or are we going to try and do something uniform? I am seeing
selectors proposed that will have to be parsed, rather than merely passed
directly to the server, which leads me to wonder whether we shouldn't think
about (* oh, no *) a STRUCTURE.

Mark, I'd also like to see something about how attributes are to be
handled, even if it's brief. For example,

gopher://host/0selector%09!

Returns the attributes. This is very different than

gopher://host/0selector

which actually fetches the item. The implecation here (and for ASK+
blocks) is that what happens cannot be determined merely by looking at the
single character gtype, you must know whether it's gopher+ or not.

- Next message: Mark P. McCahill: "Re: gopher+ support in the URL draft."
- Previous message: Mark P. McCahill: "gopher+ support in the URL draft."
- Maybe in reply to: Mark P. McCahill: "gopher+ support in the URL draft."
- Next in thread: Mark P. McCahill: "Re: gopher+ support in the URL draft."