My point exactly -- except I was trying to emphasize what this
implies for the *server* end of things.
> Therefore, the file upload widget should not just be an
> upgraded TEXTAREA.
Call it a MIMEAREA, if you like. But the file sizes are not relevant
-- the MIMEAREA doesn't actually have to actually display or even
load the contents of the files. It could, for example, simply
contain icons representing the files. The contents of the files only
need to be handled when the form is submitted.
As for the exact GUI, perhaps we should look at MIME-based mail
programs, which presumably have already found good interface
metaphors for composing multimedia documents for transmission.
NeXT's mail program, for example, uses a simple drag-n-drop metaphor.
> 3) CGI script code libraries for handling file uploads
> would be a great help (although not absolutely
> necessary).
You are brushing the server-side changes -- exactly the part of
Ernesto's proposal that I find most troublesome -- under the rug.
His proposal places new constraints (statefulness) on HTTP servers,
and adds new complexity (cascading transactions) to them as well. It
changes the semantics of HTTP for, as far as I can see, no solid
reason. I feel that this will be cause for much regret down the
road.
Fortunately, the encoding discussion is part of either proposal. But
what I'm advocating requires no other changes on the server end. We
need to keep server design as simple as possible, in order to open up
the role of information provider to the largest number of people.
--------------------------------------------------------------------
Paul Burchard <burchard@math.utah.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------