[6177] in www-talk@info.cern.ch
File Upload: Outstanding Issues
daemon@ATHENA.MIT.EDU (Fisher Mark)
Mon Oct 17 16:26:37 1994
Date: Mon, 17 Oct 1994 21:23:41 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: FisherM@is3.indy.tce.com
From: Fisher Mark <FisherM@is3.indy.tce.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
1) I contend that textual data (including HTML) is only one type of data to
be uploaded. If you look at the sheer volume of data (size of the files),
graphical data like MPEG movies, CAD drawings, maps, etc. is likely to be
the majority of the data in use. Therefore, the file upload widget should
not just be an upgraded TEXTAREA. This, of course, is coming from someone
whose bread'n'butter for 10 years has been CAD software (he says while
donning asbestos suit...).
2) I can see two distinct scenarios for file uploads. The first is when the
user knows the filename (perhaps having copied it to their window system's
clipboard), so they just want to give the widget the filename. The other
scenario is when the exact filename or filenames are not known or easily
remembered, so a "file open"-type dialog box would be of immense help. The
Microsoft Windows Visual C++ tool has a reasonable dialog box for the second
scenario in its project (collection of files) management toolset. These
scenarios imply to me a widget like (in character GUI form):
+-------------------------+ +---------+
File(s): | | | Open... |
+-------------------------+ +---------+
(a) (b) (c)
which is a composite widget made up of (a) static text identifying it as a
file upload widget (text replaceable as needed); (b) a TEXTAREA for the
first scenario (single known filename); and (c) a button that brings up a
dialog box for the second scenario. Although no other HTML widget brings up
a dialog box, I think that it is justified here so that the capabilities of
the dialog box are available without necessarily using all the screen space
needed by the dialog box (which at the very minimum would require 1 edit box
(current file like (b) above) + 2 listboxes (current directory listing and
list of files to be uploaded) + 2 buttons (Add and Delete) + associated
static text). If drag'n'drop were used to add the files, the listbox for
files to upload in the dialog box would give the necessary feedback to users
that they had dragged and dropped the correct files.
3) CGI script code libraries for handling file uploads would be a great help
(although not absolutely necessary).
4) If file uploads are to be used as the standard mechanism for updating
documents in a Web, a definition of this standard is needed.
There are probably more issues than these; I just can't think of them at the
moment.
======================================================================
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."
