The proposed widget is interesting, but I am concerned because HTTP POST
would become the only HTTP method that does not follow the simple "single
request-single response" design of other HTTP transactions. With the
proposed widget, the server will have to wait for the CGI script to complete
before it can complete the transaction, or impose an arbitrary time-out on
the transaction (another server configuration parameter!). The client,
meanwhile, has to wait on the server's response before it can end the
transaction at its end. IMHO, the proposed method would not have the
(current) HTTP nature.
The larger question is, "How often would multiple files need uploading?".
As a software developer and a Webmaster (both professions requiring working
with groups of files), I find the common case is editing of one file.
Multi-file operations are handy at the start of a project or when porting
code. For the sake of logical partitioning, modifications should extend
across as few files as reasonable without glomming everything together into
one big file.
The widget I have proposed uses a single-line edit box, a button, and a
simple file-selection dialog box. The HTTP protocol would need no changes
to handle this widget while still enjoying the benefits of receiving files
on top of the current reception of form parameters. There would need to be
a separator between the CGI variables and the files; a CR-LF pair would do
nicely.
======================================================================
Mark Fisher Thomson Consumer Electronics
fisherm@indy.tce.com Indianapolis, IN
"Just as you should not underestimate the bandwidth of a station wagon
traveling 65 mph filled with 8mm tapes, you should not overestimate
the bandwidth of FTP by mail."