[webkit-dev] Directory upload experimental feature

Wed Jun 2 07:00:28 PDT 2010

Zip files cannot be streamed (there was a good discussion in [1], so you are
unable to do any operations on the data until the entire .zip file has been
received as the central directory comes at the end. Aside from that, what if
you want to upload a large amount of already compressed files, e.g. a bunch
of JPEGs or MP3s? Zipping them won't actually do much, but it could be a
nontrivial cost in terms of cpu, memory, or both, and would introduce
unnecessary delay. On the server side, this would then require someone to
deal with zip files, and again deal with it as a big chunk rather than
acting on individual files as they come in.

I think the approach taken with <input file=multiple> is preferable, and
this seems like a natural extension of that, so I don't see why one would go
back to zip files.

-Ian

[1] http://www.mail-archive.com/public-webapps@w3.org/msg08457.html

On Wed, Jun 2, 2010 at 3:44 AM, David Kilzer <ddkilzer at webkit.org> wrote:

> > Other alternatives?
>
> I believe Safari will zip a folder and send it as a single file for you if
> you attach a folder to a file upload element instead of an individual file.
>
> Dave
>
>
> ------------------------------
> *From:* John Gregg <johnnyg at google.com>
> *To:* Sam Weinig <sam.weinig at gmail.com>
> *Cc:* webkit-dev at lists.webkit.org
> *Sent:* Tue, June 1, 2010 3:09:00 PM
> *Subject:* Re: [webkit-dev] Directory upload experimental feature
>
> My proposal for that is that all the files would be listed in the form
> submission the same way as if it were a <input type="file" multiple>, but in
> the Content-Disposition header, the filename component would contain the
> path information.
>
> One alternative idea would be add a "path" component to the
> Content-Disposition header alongside the filename which remains unchanged,
> but I think that would be a much more difficult approach.  Other
> alternatives?
>
> Example follows.
>
>  -John
>
> If you are have these files
> /home/John/photos/vacation/1.jpeg
> /home/John/photos/vacation/2.jpeg
> /home/John/photos/conference/1.jpeg
>
> and choose "photos" from the directory picker, you'd end up with
> input.files[0].name = "1.jpeg"
> input.files[0].path = "photos/vacation/1.jpeg"
> input.files[1].name = "2.jpeg"
> input.files[1].path = "photos/vacation/2.jpeg"
> input.files[2].name = "1.jpeg"
> input.files[2].path = "photos/conference/1.jpeg"
>
> Your POST would look like
> Content-type: multipart/form-data; boundary=----WebKitFormBoundaryFoo
>
> ----WebKitFormBoundaryFoo
> Content-Disposition: form-data; name="input";
> filename="photos/vacation/1.jpeg"
> Content-Type: image/jpeg
>
> <contents>
>
> ----WebKitFormBoundaryFoo
> Content-Disposition: form-data; name="input";
> filename="photos/vacation/2.jpeg"
> Content-Type: image/jpeg
>
> <contents>
>
> ----WebKitFormBoundaryFoo
> Content-Disposition: form-data; name="input";
> filename="photos/conference/1.jpeg"
> Content-Type: image/jpeg
>
> <contents>
>
>
> On Sat, May 29, 2010 at 10:22 AM, Sam Weinig <sam.weinig at gmail.com> wrote:
>
>> How will the directory structure and all the files therein be represented
>> in the form submission?
>>
>> -Sam
>>
>> On Fri, May 28, 2010 at 3:17 PM, John Gregg <johnnyg at google.com> wrote:
>>
>>> Hi WebKit,
>>>
>>> I recently proposed adding directory upload support to HTML via a new
>>> <input> attribute to whatwg@, and the discussion arrived at "try it
>>> out".  Having written some code I think I have something that works pretty
>>> well, and I'd like to land it on an experimental basis in WebKit, but want
>>> to reach out early before trying to put any code in the tree.  The plan that
>>> comes to mind is a new ENABLE_DIRECTORY_UPLOAD flag, but I'm completely open
>>> to other options.
>>>
>>> Background (cf. the whatwg thread
>>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html
>>> ):
>>>  - The use case for this is a photo album or file manager web
>>> application, which wants the user to easily choose an entire directory to
>>> recursively upload, while preserving the sub-directory structure.
>>>  - The reason for the new attribute is to signal the UA to show a native
>>> folder-picker rather than a file-picker, which on most OSs are two distinct
>>> dialogs.
>>>
>>> The approach I'm using has 2 parts and is a small amount of WebCore code
>>> (about 200 lines).
>>>  - Extend HTMLInputElement to support the directory attribute, which is
>>> passed up via FileChooser allowing the UA to display a folder-picker.  UA
>>> enumerates all the files and returns them in the normal way.
>>>  - Extend File to have a File.path property, which contains the path
>>> information starting from the chosen directory as the root.
>>>  HTMLInputElement is responsible for generating these values from the list
>>> of files when the directory attribute is set.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>>  -John
>>>
>>>
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100602/2998922d/attachment.html>