> > The "state-less-ness" of browsers shouldn't be under
> estimated.  Usually,
> > "cookies" are used to preserve the state of the
> application, but other
> > tricks can be used.  In any case, think additional
> complexity, and more
> > importantly, a different way to program the task at hand.
>
> This goes double if your coming from a prompt -> response (TTY)
> model of programming UI and not View (or other forms).

And so we come to the real hurdle in getting to browser-based apps:
not the user-browser interface, but the server-browser state
negotiation: who keeps track of what, where do they keep it, and how
do they share it? As Lars has mentioned, maintaining that state using
current technology is not for the faint of heart. And as Richard
points out, for developers used to the paradigm of
   a server that maintains a lot of state information,
   a client that is little more than an infinitesimally intelligent
(but fast!) piece of paper, and
   a "do this, don't do that, <trivia: what goes here?>" interaction
completely controlled by the server
the browser-style app requires some distinctly non-trivial changes to
the usual way of doing things. W3C XForms and MS's Web Forms look like
a good start on solving these problems; at a minimum, they let us
start playing with browser-based designs. Like many others, I think
the browser-style "invisible client" apps will become dominant--as
soon as we figure out how to make them work.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *