Date: Thu, 10 Mar 94 09:34:22 CST
Message-Id: <9403101534.AA02799@boombox.micro.umn.edu>
From: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>
To: hoymand@joe.uwex.edu, uri@bunyip.com
Subject: Re: gopher+ support in the URL draft.
In message <9403101408.AA17848@joe.uwex.edu> Dirk Herr-Hoyman writes:
> Mark, Thank for your thoughtfull explainations of why you have changed the
> gopher and gopher+ URLs,
its a single URL that accomodates all flavors of gopher
> and as to whether we should have a uniform search
> syntax. I as I probe these questions, kinda like a sore tooth in my mouth
> :-), I hear myself flip/flopping back and forth as to whether a uniform
> syntax is a good idea.
>
It sounds like you are at least half convinced that there are
problems with requiring a uniform syntax. That's good.
> But, let me get back to your proposal. There is another sore tooth there
> for me, the search field.
>
> > At 7:17 PM 3/7/94 -0600, Mark P. McCahill wrote:
> >...
> >So, the format of a Gopher URL path refering to a gopher type "T" item is:
> >
> >gopher://host [port]/T[gopher_selector]%09[search_string]%09[gopher+_string]
> >
>
> Why can't you just let the opaque string be, in fact, the gopher0/gopher+
> selector, with escaped tabs (and spaces and ...)? Just plain old:
>
> gopher://host [port]/T[gopher_selector]
>
> The search gets done with the tab, but now it's not a null field for any
> non-searches. And you just tack on the gopher+ field, like your examples
> (and thank you for adding these, very helpful) show. If it works for the
> gopher server, it should work here too, right?
>
As I said before, there are a lot of different syntaxes that could
say the same thing.
The one I chose was a balance between being backward compatible with
existing gopher URLs while still accomodating Gopher+. The syntax I
chose lets you figure out what the parameters are by counting the
encoded <tab>s; this does mean that there will be null fields sometimes.
Being able to know what the parameteres are by counting the <tabs> makes
this easy to parse.
Another approach that was considered and rejected was to require all gopher
URLs to have the same number of fields because this would be super-easy to
parse. The problem with that is it would have broken every single gopher URL
currently in existance.
Mark P. McCahill
gopherspace engineer/University of Minnesota
mpm@boombox.micro.umn.edu
612 625 1300 (voice) 612 625 6817 (fax)