On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren <span dir="ltr"><<a href="mailto:annevk@opera.com">annevk@opera.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5">On Fri, 11 Dec 2009 09:33:06 +0100, Markus Ernst <<a href="mailto:derernst@gmx.ch" target="_blank">derernst@gmx.ch</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anne van Kesteren schrieb:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst <<a href="mailto:derernst@gmx.ch" target="_blank">derernst@gmx.ch</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have no idea how to handle such inconsistent behaviour on the server side (except adding extra code to flatten all uploaded directory structures before handling). I assume that HTTP upload should be kept simple, and more complex upload tasks should be handled with specialized applications, such as RadUpload[1].<br>


<br>
[1] <a href="http://www.radinks.com" target="_blank">http://www.radinks.com</a><br>
</blockquote>
<br>
I don't think we want to rely on the availability of Java on the end user's platform (or the availability of any other plug-in for that matter).<br>
</blockquote>
<br>
I did not mean including it into HTML5 or an UA. Just leaving specialized upload tasks out of the standard, assuming that developers will work with applications that they think are useful for their tasks (and that rely on technologies they believe are avaliable at their target audience).<br>


</blockquote>
<br></div></div>
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.</blockquote><div><br></div><div>I (and I think most of us) strongly agree.  That's the whole point of standardization.  :-)</div>

<div><br></div><div>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.</div>

<div><br></div><div>But regardless.....I don't think you could argue that having _some_ path information is worse than _none_, right?</div><div><br></div><div>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.</div>

<div><br></div><div>And, with or without that extra property, I think what Ian's suggesting would be useful to users.</div><div><br></div><div>J</div></div>