> It would be useful if you could be more specific. For
> example, how would you put a 100MB binary image file into
> the upgraded TEXTAREA? Please explain the behavior of
> the upgraded TEXTAREA in more detail.
The TEXTAREA would serve as a MIME-based multimedia text field. The
GUI could vary, but for example, it might allow you to drag-n-drop
file icons into the field (along with text if you so chose). Fancier
GUI's might display the multimedia components non-iconically, but
that's not essential. When the FORM is submitted, the files would be
collected, and the browser would create multipart MIME to encode the
field's multimedia content.
> (By the way, some server applications already keep state
> information with the help of forms' HIDDEN fields.)
I think you misunderstand -- the *client* is the one keeping the
state information in the HIDDEN fields; this has no bearing on the
statefulness or statelessness of the server.
The current transaction model with HIDDEN fields provides great
flexibility for application designers to balance the burden of state
maintenance between the client and the server -- including placing
the full burden on the client, which is often quite efficient and
cost-effective. The scheme you propose would greatly complicate the
model and preclude the possibility of stateless servers for many
applications.
> Servers would only become stateful iff the writer of the
> forms chose to make it stateful. Let me explain with a
> ficticious example. Suppose I'm a book editor and I put up
> a server so that authors can submit manuscripts for my
> review. I make a form that includes an INPUT tag of TYPE
> "file", where the author will enter the paths to all the
> chapters that make up his manuscript.
[...details deleted...]
Even in this simple example of file submission, there appears to be a
problem with state. How does the second CGI script know to which
author to attribute the incoming manuscript -- and thus, where to
send the check? :-) That information was given to a different
script. With the various FORM data being fed to the server in
separate submissions, using separate scripts, how will that data be
re-coordinated without forcing the server to maintain pending
transaction records? And even then, the later scripts must
apparently be invoked by varying URLs containing a transaction key,
so that the second script knows which transaction record to look at
(you can't just key on the file name; what if two authors both submit
"my_novel.wp"?).
This all becomes much more important for the more complex services
that people are envisioning based on the ability to perform file
submission in FORMs. Stuff like image processing, mathematical
operations on geometric input, and so on. In all of these cases, the
services offered will be highly parameterized, requiring lots of
multimedia input. In your scheme, providers of such services do not
have a choice but to build stateful servers with 2, 3, or more
cascading scripts all linked into a pending transaction database.
> My main interest is getting file upload into the WWW.
Mine too. But I would like to jealously guard the relatively clean
transaction model of HTTP -- I think that's one of its great
strengths as compared to other interactive services (such as WAIS).
--------------------------------------------------------------------
Paul Burchard <burchard@math.utah.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------