[whatwg] Uploading directories of files
ojan at chromium.org
Fri Dec 11 13:12:43 PST 2009
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).
> (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.
> 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
>>>> 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...
More information about the whatwg