Re: Idea for new form input type

• Mail folder: WWW Talk Jan 94-present
• Next message: Mark Krause: "WAIS -> WWW Gateway and Titles"
• Previous message: Ian Dunkin: "Re: Proxy Servers (and SOCKS)"
• Maybe in reply to: Fisher Mark: "Re: Idea for new form input type"

Errors-To: listmaster@www0.cern.ch
Date: Fri, 25 Feb 1994 23:38:27 --100
Message-id: <199402252235.OAA15605@netcom9.netcom.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: satie3@netcom.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: satie3@netcom.com (David Parker)
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: 2600

>Dave,
>>Lou,
>>
>>> In order to support the posting of large files using form based
>>> machanisms I suggest that a new input type "include-file" (or
>..
>>> The reasons this will be useful are as follows:
>>> * large text files can be sent without having to cut and paste
>>>   them into a textarea window as they are now.
>>> * no memory limits on the size of the file.  (currently all input
>>>   data is held in memory)
>>> * arbitrary binary files can be sent
>>
>>Seems good to me, I guess smart browser could also support drag 'n drop.
>>Tim Berners-Lee suggested a while back now, that you should be able to
>>paste (or drag 'n drop) arbitary data into a TEXTAREA field with the
>>browser being responsible for managing the encapsulation when sending
>>it to the server, and also how to present the pasted data to the user.
>>The browser could default to showing the file name and size if it doesn't
>>have any other way of displaying the file/object in the widget.
>>
>>One way of combining the two ideas is for the TEXTAREA widget to show
>>a file menu in addition to the vertical and horizontal scrollbars.
>>Surely this more general approach would be better than a simple file
>>name widget?
>>
>>Dave
>
>This approach would not address the problem of non text files very well.
>Should a CGI script have to be prepared to handle a MS Word document as
>well as ASCII text from a text area field?
>
>Should the form allow the specification of a desired/required MIME content
>type for the file to be named?
>
>Should there be a mechanism for specifying the MIME content type of the
>file to be sent?
====
Rob:

I agree that there is a urgent need for an 'include-file' feature.  As an 
example, I have been beating my head to find a way to reference and 
download self-extracting files.  I _do not_ want to open it or filter it
in any way - only save it locally from a file server.  At this time, I know
of no way to do it.  I think include-file feature would cover this.

This does not have to 'smart.' It could be as simple as a reference to the 
file like the existing URL.

One possible script for this could look like, <A HREF=includefile://...> and
<A HREF=includehttp://...>

There should NOT be a MIME content type for the file: it is too complicated
and defeats the nature of the transfer one is trying to achieve (anonymous
file types).

Regards,

David Parker                                                    408/285-7718
Database Specialist                                       satie3@netccom.com
Tandem Computers. Inc.                             Parker_David_F@tandem.com