[whatwg] Uploading directories of files

2009/12/11 Ian Fette (????????) <ifette at google.com>

> 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.)
>

What happens if the user then adds a single file from a different directory?
Or if the user adds a second directory? Would the input element just
disallow that or would all the paths be updated?

Also, should the paths use the OS path separator or always be "/"? The
latter seems preferable to me. Less OS specific code in the web platform.

Ojan


> 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/edecf692/attachment.htm>

Received on Friday, 11 December 2009 13:12:43 UTC