Date: Wed, 31 Jan 2001 11:33:47 -0500
From: David Allen <s2mdalle@titan.vcu.edu>
To: gopher@complete.org
Subject: [gopher] Re: ASK blocks in practice
Message-ID: <20010131113347.A5281@mothra>
References: <20010121231920.A14344@mothra> <20010122111235.30433.qmail@softhome.net> <20010122121219.B17731@mothra> <20010130183017.D44DC7CC2@hirogen.kabelfoon.nl> <20010130180557.A396@mothra> <20010131161247.D0C107CC2@hirogen.kabelfoon.nl>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <20010131161247.D0C107CC2@hirogen.kabelfoon.nl>; from StefanRieken@SoftHome.net on Wed, Jan 31, 2001 at 05:13:12PM +0100
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org

On Wed, Jan 31, 2001 at 05:13:12PM +0100, Stefan Rieken wrote:
> > This is a problem.  See above with the question of whether or not a
> > script can legitimately output directories.
> 
> Well, I guess that with the current ASK implementation, a script should
> normally _always_ output a single data type, and in 99,999% of the cases
> this data type should be a directory. (It may be hypothetically possible
> to have it output nothing but images instead - e.g. a different image
> depending on the user's input), but I don't think anyone would ever use
> that wicked capability in practice, anyway.)
> 
> Then I also guess that we have no choice but to have our "newstyle"
> script also only to output directories. Is this a disaster? I guess it
> isn't. As shown above, in 99% of the cases, this _is_ what is expected
> from a script, anyway.

I'm still not clear on how to make this happen.  Whenever I write
scripts, they always, always output plain text, and that's what the
client interprets it as since the script is flagged as type '0'.  So
even if I output the protocol info for a directory, the client
interprets it as text.  So how do you do this?  How in any case do you
get a script to output something that is interpreted as anything other
than text by the client?

> > So I know I might be jumping out of the immediate frame of discussion,
> > but is extending gopher to do these types of things worth it, or is
> > that really what the web is for?
> 
> Oh, was _that_ your question? ;-) Right.

Yeah, that's what I was driving at.  The end goal is to have a certain
set of functionality.  If it's a large addition that needs to be added
to later, you may as well package it as an extension rather than
implementing the hacks you were talking about in your last email.

> *Sigh.* I think you might be right, but I don't like the idea.
> 
> The modern use of HTTP really depends on its CGI capabilities. If Gopher
> can't support stuff like that, is it strange that it's not an option for
> many people anymore?

<devils_advocate>
Well that is also at the crux of what I was saying.  FTP isn't going
all out to try to be like HTTP.  It may be that yes, gopher won't fill
a niche for people like the web does, but is it supposed to?
Historically people used gopher before the web, but that doesn't mean
that they should do the same things.  So do they have different
niches?  People would think it absurd to try to work in CGI features
into mail transfer protocols, because sure, you could staple on the
functionality in MUAs and MTAs, but that's not their niche.  So why
extend gopher?
</devils_advocate>

> And we wouldn't even be there yet with just CGI. How about cookies,
> authentication? Evil as cookies might be, they are used for personal
> settings etc. all over. Implementing _such_ stuff in a
> client-independent manner isn't doable at all. So I guess you're right
> that all this might be not worth it.
> 
> But that also shows that Gopher wouldn't really live up for the future.
> It's niche (webbrowsing without the hubbub) might not survive the
> comparision to HTTP's niche (dynamical and personal approaches of people
> and data).

Well, it seems something needs to happen, because as for the
structured heirarchy of directories with lots of downloadable
information in each one and optional subdirectories, there are
graphical FTP clients that can do everything that gopher is currently
used for.  Using a graphical client where your anonymous login is
transparent, and then a sorted list of directories and files, all
you'd have to do is change the look and feel, add the equivalent of a
built in text viewer, and you'd have something that could fool people
into thinking it was a primitive gopher client.

What I want to know is what people consider the 'soul' of gopher that
sets it apart from HTTP, and even FTP.  That's the direction I want to
go in.  I'm not sure that anybody is interested in extending gopher to
reimplement the wheel.  Or?

> BTW, could you tell me how the Gopher+ protocol is unclear and
> misunderstood, as you said?

That's not my personal opinion, but it's one that I've heard voiced
here several times.  I like gopher+ quite a bit, but I know that there
are some people on this list that don't, and that was one of the
reasons that they stated that I remember, that some parts of the
gopher+ spec could be read in a way as to make them seem contradictory.

> Conclusion: I don't know. If you feel like it, hack it in and see what
> evolution thinks of it. For the more advanced stuff like authentication,
> I do see limitations that couldn't be solved without introducing
> Gopher++, but I don't think Gopher would survive yet another (backwards
> compatible) protocol revision. But if we keep Gopher for what it is,
> what does it make it _really_ different from e.g. LDAP? (OK, I _guess_
> (I don't know much of it) LDAP isn't meant to be a "browser" protocol,
> but with Nautilus supporting LDAP, for me it doesn't make any real
> difference.) If Gopher really loses its niche by sharing all of its
> advantages with a few more supported protocols like HTTP and LDAP, then
> what is it still worth using it at all - not even talking about
> extending and maintaining it?

I'd like to get more feedback from other people as to what they think
gopher's niche is before that investment is made.

-- 
David Allen
http://opop.nols.com/
----------------------------------------
http://www.oreilly.com/catalog/cookbook/author.html
Nathan Torkington, Co-Author of the Perl Cookbook
Nathan Torkington has never climbed Mount Kilimanjaro. He adamantly
maintains that he was nowhere near the grassy knoll. He has never
mustered superhuman strength to lift a burning trolley car to free a
trapped child, and is yet to taste human flesh. Nat has never served as a
mercenary in the Congo, line-danced, run away to join the circus, spent a
year with the pygmies, finished the Death By Chocolate, or been
miraculously saved when his cigarillo case stopped the bullet.