From: raisch@Control.COM (Robert Raisch)
Newsgroups: alt.gopher
Subject: Extensions to Gopher, (Blue Sky Thinking...)
Date: 15 Apr 92 21:19:42 GMT
Distribution: alt
Organization: Control Technology Corp., Hopkinton MA

During the time I was net-admin for Michigan State University,
I attempted to interest the powers that be in a Gopher-like system which 
we dubbed 'netMSU'.  The purpose of netMSU was quite similar to what gopher 
offers today with some interesting differences.

netMSU was designed to be an "Andrew" - like system which answered
the needs of the least common denominator, (a vt100 terminal).  It 
integrated mail, news, bulletins(documents), file downloads, graphics
(rudimentary), and various control features, and was meant to be 
run on PCs, MACs, VM/CMS, VMS, and Unix systems, giving each user
no matter the actual architecture peer based access to the information
that was available.

gopher does a portion of this, but because of it's adherance to a
'state-less' server philosophy, it cannot, (without extensions),
offer much more.

For example, without user verification, the availability of news and mail 
could only be offered in a VERY limited fashion.

Also, without the ability of the client to ADD to the database in different
ways, gopher remains a static tool for the 'presentation' of information,
instead of a dynamic method of creating new information.

Furthermore, since there is little knowledge of the client, from the 
server-side, many potential types of file are unavailable to the gopher-ite.

One possibility:

	If files on the server were tagged with a translation table of
	filters, which when run on the source file would produce a file
	of a form recognizable to the client.

		An example of this would be a RichTextFormat document,
		converted to Postscript for a client which understood
		only Postscript.  Or converted to plain_text for a
		client with only simple features.

		Perhaps also, a GenericBitmap file converted to Encapsulated
		Postscript for display on a Postscript capable host.

	During the initial stages of the retrieval of an "object" from a
	server, the client could send a discriptor which would tell the
	server what formats the client could handle.  Thus allowing the
	server to make conversion decisions.

	I realize that these conversion possibilities are not trivial
	issues.  The probability of having to support many formats is
	great.  But that is what the 'distribution' of gopher should be
	about.  I have Postscript files here, for reading by anyone who
	does not 'do' Postscript.  I can convert them to plain_text, or
	to RTF.  Someone else, given the need of the community, might
	be able to offer the same documents in other forms.  Don't 
	limit the possibility of what gopher can do because of perceived
	problems down the road.

	Also:

	This could also be handled on the client side, so that all documents
	during transmission could be encoded in a more efficient form than
	that of plain text.


	Scenerio:

		Server has a document called 'What I did on my Summer Vacation'

		Client requests that document, and mentions that she would
		appreciate the document more if it were available in TeX
		format, or perhaps Postscript.

		Server decides that TeX is out of the question, since the
		native form of the document is Postscript, and so sends the
		document to the client.

		Ahh, but the client informed us that she could handle Unix
		style compressed files, so before the document leaves the 
		server it is compressed using "/usr/bin/compress".

		It arrives at the client, who looks at the file and decides
		that it is compressed, uncompressed it, and then looks to
		see if it is a TeX file.  It is not, so perhaps it's a 
		PS file, ahhh... I see by the required '%!' that it is a PS
		file, so I display it thusly.... &c.

Perhaps:

	All of these "decision" transactions could happen over another 
	TCP/IP port, and first the client opens the server's control port,
	tells the server who the client is, the server would return a 
	unique transaction identifier, which the client would use for the
	current session to identify itself to the server.

	Thus, using some appropriate magic, a timestamp and unique ident
	could be combined and encrypted, thus giving the client the
	ability of conclusively identifying itself to the server.

	Thus mail and news(posting) could be offered to the clients.

	+---------------+
        |               |                 +--------------------+
        |  CLIENT       |                 | Control Server     |
        |               |       +-------> | Hands out tickets  |
        |               |       |         | based on identity  |
        |               | <-----+         +--------------------+
        |               |                 |                    |
        |               |                 | Standard Gopher    |
        |               | <-------------> | modified to accept |
        |               |                 | tickets            |
        +---------------+                 +--------------------+

A personal opinion regarding SECURITY:

	In a campus wide information system, there is just so far that you
	can go to secure the identity of a user of a system such as this.
	If you are the overly paranoid type, Kerberos could be used, but I
	really feel as if that would be overkill.

	All we really need is a certain level of confidence that the user
	who is sending and receiving data can be identified to our satisfaction.

	Hell, we don't feel that bad about reading our mail, in plain text
	between our Unix host and local terminal, or our Vaxen and our VT100.

	I suggest that you either go completely overboard on security or you
	"do your damnest" to keep a high level of confidence in the identity
	of your users.  A timestamped id, encoded and sent along with each
	object request is more than enough.  (IMHO)

News:

	One thing that I would really like to see, and it would be reasonably
	trivial, is a 'decent' newsreader based on gopher.  One which would
	handle threading of articles and present them in a reasonable form.

	Something like:

	<dir>	1. Article the First, Author: Wiggins, (3 replies)
	<text>	2. Article the Next, Author: Severence
	<text>	3. Article the Last, Author: Greenberg

	Where the directory presented upon selecting 1 would look like:

	<text>	1. Article the First (original) Author: Wiggins
	<text>	2. Re: Article the First (reply) Author: Davis
	<text>  3. Re: Article the First (reply) Author: Nelson
	<text> 	4. Re: Article the First (reply) Author: Moore


	Of course, a newsreader would be of limited use if it did not also
	allow posting.  (see above)

	This type of newsreader is only another filter on raw data.

Filters:

	The possibilities of other "intelligent" filters is rather boggling.

	o	A filter could create a new hierarchy of documents and 
		directories which would change based on the current state 
		of the information.

	o	Filters could be based on 'expert systems' front ends, and 
		make decisions for the client as to what *should* be 
		available for viewing at a particular point.

	o	Filters could also act as 'active agents' to collect 
		information for a particular client.  (Knowbots.)

A word from our sponsor:

	Few are probably aware of the current initiative from such entities
	as Merit, ANS, NSFNET, FARNET, NREN, but the interest in BANDWIDTH has 
	cooled down a lot, and the current hot button is SERVICES.

	There is an awful lot of REAL MONEY out there for a research 
	project in just this kind of technology.  ( I wonder if
	Lew reads this group? ;)

	When this finally shakes out, and with the (I pray) intercession
	of the EFF in terms of ubiquitious residential networking, it is
	services like these which will create the information topologies
	of the future.

	Our children will be using gopher, or it's descendants to navigate
	the bright new world of information that we are building here and
	now.

	It is our duty as citizens of the internet to forge the new hammers
	of the next generation of internetworks.

	(I tend to wax a trifle pendantic at times, apologies.)

And finally,

	To the authors of gopher...
  		Congrats.  It's a good start.  I love it.


	Fondly, /rr	<waves to all his friends at MSU>
-- 
"What makes you think that you can dictate how people love each other?" -Soren
Copyright 1991 by raisch; contents cannot be sold for profit without permission.