[whatwg] Uploading directories of files

Ok, I sense resistance to putting it in .name. What about .path, undefined
in most cases except where there is an upload including files from multiple
directories, in which case .path contains the path less any path components
common to all 3 (sorry, it's early morning and I can't write well before
having coffee).

e.g.

input.files[0].name="1.jpg"
input.files[0].path="a/b"
input.files[1].name="2.jpg"
input.files[1].path="a/b"
input.files[2].name="3.jpg"
input.files[2].path="a/c"

(Need to figure out the exact wording, as "a" is common to all 3 but if
you're uploading the entire directory "a", it may make sense to include that
in the path -- but I don't feel quite as strongly about that -- subfolders
are certainly more important IMO.)

2009/12/11 Jeremy Orlow <jorlow at chromium.org>

> On Fri, Dec 11, 2009 at 2:30 AM, Markus Ernst <derernst at gmx.ch> wrote:
>
>> Jeremy Orlow schrieb:
>>
>>  On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren <annevk at opera.com
>>>
>>
>>     And I mean that if it is important to application developers we
>>>    should make it available as a feature and not endorse some plug-in
>>>    dependency.
>>>
>>>
>>> I (and I think most of us) strongly agree.  That's the whole point of
>>> standardization.  :-)
>>>
>>> Personally, I don't think the case Markus pointed out is at all a show
>>> stopper.  In the case of images, the server could easily recognize and
>>> reconcile duplicates (by hashing them and looking for duplicate hashes or
>>> something).  If the image has been tweaked some in the mean time, the EXIF
>>> data can help.  And so on....this seems like the type of thing clever
>>> developers can work around.
>>>
>>> But regardless.....I don't think you could argue that having _some_ path
>>> information is worse than _none_, right?
>>>
>>> I also agree with Jonas that if some path information is added, it might
>>> be better to create a new property (other than .name) for it.
>>>
>>> And, with or without that extra property, I think what Ian's suggesting
>>> would be useful to users.
>>>
>>
>> Yes I see Anne's and your points. Anyway I don't see yet how to get
>> _useful_ path information, as the same file can be posted as /a/b/1.jpg, and
>> at the next occasion as 1.jpg or /b/1.jpg, just based on where in the upload
>> dialog you did make the start point.
>>
>> Relying on information contained in the uploaded file does not seem to
>> make sense to me, as you might want to upload a new file with the same name
>> in order to replace the old one.
>>
>
> The information in the path could be seen as a hint that may or may not be
> provided.  I feel like it'd be difficult security wise to guarantee that the
> hint will be there and/or consistent from upload to upload.  But, once
> again, some hint is better than none, right?  If you as a web developer
> don't think it's useful, you can ignore it, right?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091211/ad246972/attachment-0001.htm>

Received on Friday, 11 December 2009 06:24:37 UTC