[whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Kinuko Yasuda]

On Thu, Nov 17, 2011 at 3:21 AM, Glenn Maynard <glenn at zewt.org>
wrote:> I don't think it's possible to do this correctly, because URLs
created with> toURL have no equivalent to revokeObjectURL.  A
long-running page has no way> to avoid "leaking" these references
until the page exits.  Adding a revoke> method for toURL would
essentially turn it into URL.createObjectURL.>> Needing to revoke URLs
when dealing with worker communication also makes it> very hard for
users to get it right.  For example, suppose a Window sends a>
toURL-generated URL to a Worker.  How do you ensure that the URL is
revoked> after the worker has received it and finished converting it
back to an> Entry?  The Worker might be killed (eg. due to CPU quotas)
at any time,> making avoiding resource leaks very hard.
I assume filesystem: URLs are like files: URL (but with the origin info);
the actual data resides on-disk and the URL is a locator to the
localresource, but not the 'live' reference that controls the lifetime
ofthe resource itself.  Similarly having URLs (or Entry) doesn't mean
the holder can access the underlying file.  The file could be removed
or moved by other scripts or by anyone in non-sandboxed cases.

If we apply the current URL model to non-sandboxed cases, passing
URLs wouldn't imply anything about the lifetime (of the data or of
access rights) and the access rights would simply expire when the
context where the Entry was created goes away.  This would limit
several possible scenarios like the ones you noted but would still
be consistent.  (please read on)
> These are just the usual problems with manual resource management, which> should be avoided if at all possible.  We already have a mechanism that> cleanly avoids all of this, with structured clone and File.
Having said that, I'm kinda convinced that structured cloning might
give a clean solution and open up more possibilities with explicit lifetime
control and capability passing.(I guess, though, if we continue this
discussion maybe we should split
the topic and move onto public-webapps?)
>> > Off-hand, the main issue that directly affects reading is that most>> > non-Windows filesystems can store filenames which can't be represented>> > by a>> > DOMString, such as invalid codepoints (most commonly mismatched>> > encodings).>>> A naive solution in filesystem approach would be silently ignoring>> such files (probably bad) or having in-memory path mapping (would be>> slightly better).  For limited read-only drag-and-drop cases we>> wouldn't need to think about remapping and the mapping could just go>> away when the page goes away, so hopefully implementing such mapping>> wouldn't be that hard.>  > There are probably some cases that we'll just have to accept will never work> perfectly, and design with that in mind.<snip>> This is complex, though, and leads to new questions, like how long the> mappings last if the underlying file is deleted.  As a data point, note that> most Windows applications are unable to access files whose filenames can't> be represented in the current ANSI codepage.  That is, if you're on a US> English system, you can't access filenames with Japanese in them.  (Unicode> applications can, but tons of applications in Windows aren't Unicode;> Windows has never made it simple to support Unicode.)  If users find that> reasonable, it might not be worth all this for the even rarer case of> illegal codepoints in Linux.
I admit that with write/rename operations such path mapping
solutioncould become very complex.  That's why I explicitly noted "if
it's forread-only cases".
> For what it's worth, I think the only sane approach here is an isolated> break from attempting to make everything interoperable, and allow the> platform's limitations to be visible.  (That is, fail file creation if the> path depth or filename length is too long on the platform; succeed with file> creation even if it would fail on a different platform, and so on.)  I think> this is just inherent to allowing this sort of access to real filesystems,> and trying to avoid it just causes other, stranger problems.
For writing cases I agree with this, or simply I cannot think of
abetter approach.  And if that's the case it might make more sense
tohandle readonly cases in the same way.