[6218] in www-talk@info.cern.ch

home help back first fref pref prev next nref lref last post

Re: File Upload: Outstanding Issues

daemon@ATHENA.MIT.EDU (Paul Burchard)
Tue Oct 18 18:30:24 1994

Date: Tue, 18 Oct 1994 23:29:20 +0100
Errors-To: postmaster@www0.cern.ch
Errors-To: postmaster@www0.cern.ch
Reply-To: burchard@horizon.math.utah.edu
From: Paul Burchard <burchard@horizon.math.utah.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>

Fisher Mark <FisherM@is3.indy.tce.com> writes:
> 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.

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...''
--------------------------------------------------------------------

home help back first fref pref prev next nref lref last post