Re: Idea for new form input type
burchard@geom.umn.edu
Errors-To: listmaster@www0.cern.ch
Date: Thu, 17 Feb 1994 02:18:22 --100
Message-id: <9402170115.AA19032@mobius.geom.umn.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: burchard@geom.umn.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: burchard@geom.umn.edu
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Idea for new form input type
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1388
> In order to support the posting of large files using form
> based machanisms I suggest that a new input type
> "include-file" (or something similar) be added. This
> new type would be a file that exists on the local machine
> whose data would be posted to the forms server during form
> submission. This method would require the file to be
> posted using a MIME multipart message.
This would be very useful....but it is unclear to me how the file
name information is supposed to be maintained and governed.
Does the user have to choose a file name every time the form is
submitted? If so, it would be far less useful. For example, it
would not solve the problem of entering large data sets into
Cyberview, our form-based 3D viewer, where the same data set is
typically used repeatedly.
On the other hand, if the file name info is maintained as part of the
form and transferred back and forth, where does that info fit into
the name/value scheme?
Is this an input-only mechanism? Why go half-way? Interactive data
processing programs on the Web will want to be able to output large
amounts of out-of-line data as well.
--------------------------------------------------------------------
Paul Burchard <burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------