A Truly Heretical Suggestion w/ URL

John C. Mallery <jcma@reagan.ai.mit.edu>
Errors-To: listmaster@www0.cern.ch
Date: Sat, 26 Mar 1994 16:04:29 --100
Message-id: <19940326150245.7.JCMA@JEFFERSON.AI.MIT.EDU>
Errors-To: listmaster@www0.cern.ch
Reply-To: jcma@reagan.ai.mit.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: John C. Mallery <jcma@reagan.ai.mit.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: A Truly Heretical Suggestion w/ URL
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2875


[losing listserve loses the X-URL header, so here it is:
X-URL: ftp://cambridge.apple.com/pub/clim/papers/clim.ps.Z]

Any chance of cleaning up the way form processing works before casting it in
stone?

	* Although I have CLOS multimethods in my Common Lisp HTTP server, it
	seems like HTTP post is overloaded when one must read random headers
	in order to decide what to do with a form.

	* The vocabulary of input types could also use enriching and some
	hierarchical typing along the lines of CLIM presentation types. (Dunno
	if Dave Raggett has got around to looking at this question. He has the
	relevant pointers.See the referenced URL.)

	* Incremental local redisplay as function of user choices would be
	highly desirable, but requires a framework for local input-relative
	computations, i.e. selection of one choice changes the set of choices
	offered.  These are essentially constraints between queries.

	* Addition of the abstraction of a query with a set of values.  I hate
	reassembling choices (values) associated with one query from
	n-different ``pseudo queries'' into one actual query.

	* Addition of some abstraction on the processing side for people who
	don't have presentation-based automatic form-processing
	infrastructure, i.e, get the values of the form and run my response
	function on them. (Maybe I don't understand what others do here, but
	my impression is that it is every man/woman scripting for
	his/herself.).

If form processing were cleaned up, I expect considerable work could be
offloaded to the client.

For standard input types, the client would be responsible for returning
syntactically correct values, freeing the server from having to handle
type/syntax errors for conforming clients.

At the same time, typed presentations and input types can allow a richer
variety of gestures for acquiring input from the user, including pointing and
presentation translation from one type to another. This also opens the
possibility of tracking what input types are on the user's display.

The important point of this UI technology is that it allows the user to
directly manipulate program data (appropriately translated) and this maintains
a tight coupling between the user model and the program model.

These ideas date from a doctoral thesis by Gene Cicarrelli at MIT in the early
1980s.  Many concepts were implemented in the Symbolics Dynamic Window System
in 1987.  These were then reimplemented (with better engineering and
simplification) in CLIM the portable Common Lisp Interface Manager, c. 1990.
To date, we know of no other window system managers which have adopted an
interaction model of this sophistication.

Before flaming, best to check out an application running a decent
presentation-based interface, and I'm sure all would agree that it would be a
really big plus if W3 could exploit at least some of the key concepts.