[whatwg] Uploading directories of files

[Ian Fette (イアンフェッティ)]

2009/12/10 Jonas Sicking <jonas at sicking.cc>

> 2009/12/10 Ian Fette (イアンフェッティ) <ifette at google.com>:
> > USE CASE:
> > Many sites allow you to upload multiple files, often images. HTML5 allows
> > this via <input type="file" multiple>. This works well when your files
> are
> > all in one folder, but it may often be the case that files are spread
> across
> > sub-folders, and in this case you have to do multiple transactions (or
> > multiple <input type=file multiple> tags, which is just awkward) to
> upload
> > your files.
> > PROPOSAL: Allow a UA to recursively select and upload a directory of
> files.
> > How the UA chooses to modify the file picker dialog is outside the scope
> of
> > this spec, but for the sake of argument, assume that the UA lets you pick
> a
> > folder and say "upload all". Allow the UA to upload the files in the
> folder,
> > with the subdirectories included in the filename with a directory
> separator.
> > E.g. assume I have:
> > C:\users\ian\a\b\1.jpg
> > C:\users\ian\a\b\2.jpg
> > C:\users\ian\a\c\3.jpg
> > If the user chooses "a", the UA should be allowed to send all three files
> > with filenames:
> > "a/b/1.jpg"
> > "a/b/2.jpg"
> > "a/c/3.jpg"
> > as it would for the existing <input type=file multiple> implementation,
> with
> > the addition of the directories and path separators (not full path, just
> the
> > directory the user chose and sub-paths.)
> > Thoughts?
>
> I don't think there is anything in the spec preventing you from doing
> this right now. The fact that only files in the same folder can be
> selected is a limitation in the implementation, not a limitation in
> the spec.
>
> The spec does require that only the leaf name, without any paths, are
> submitted. Is that a problem?
>

Perhaps not a show stopper, but I think it's sub-optimal. E.g. if I am using
a client application, I can point it to my "My Photos" directory and it can
infer some album structure from how I've organized my photos. It would be
nice if a web photo app could do the same.


>
> I guess I'd be ok with changing the spec to allow more of the path to
> be exposed. However that would mean that there is a mismatch between
> what name is submitted and what name you'd get from
> input.files[n].name.
>
>
I think that the notion of allowing more of the path to be exposed and
reconciling that with .name is where the problem lies, and would like to
figure out if we could resolve that. I think that there is a case to be made
for including the paths -- e.g. if I'm uploading photos to flickr, picasa,
or facebook, I may have already organized them locally, there's no reason
that I shouldn't be able to maintain that structure when I upload to the web
application. The question is then how that gets reconciled with
input.files[n].name -- I would think it preferable if .name also were
allowed to contain that extra information -- currently we say "The name of
the file. There are numerous file name variations on different systems; this
is merely the name of the file, without path information." [1]. I guess I
would propose that be changed to "The name of the file. There are numerous
file name variations on different systems; this is merely the name of the
file. If the user agent allows for files from multiple directories to be
selected and included in a single FileList, path information may be included
to distinguish between the files, provided that such path information SHOULD
NOT include information about any path components that are common to all of
the Files in the FileList."


Again, open to suggestions of how this could be accomplished in a better
way.

[1] http://www.w3.org/TR/FileAPI/#dfn-name

/ Jonas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091210/a84e3143/attachment-0002.htm>