directory-upload
directory-upload copied to clipboard
WICG
It isn't clear whether Directory.path should include the name of the directory itself
For Mozilla I implemented Directory.path to not include the name of the Directory itself. This seems different to File.webkitRelativePath though which does seem to include the File's name. Either way, the spec text should be clarified.
This makes me wonder if we even need Directory.path. Developers would always know where they are in the directory structure since they are traversing the Directory themselves. Having said that, do you feel that Directory.path has a valid use case?
I'm actually of the opinion that it's fairly useful and not very expensive. While developers can construct a path string themselves by keeping track of depth during iteration, it's a quick convenience property.
@aliams, @jwatt: as for whether the path should be fully qualified or not, I'd err on the side of fully qualified (that is, including the name, just like webkitRelativePath does). Of course, you can always tack on Directory.name and you'd have a fully qualified path. So there's some redundancy but it's not terrible IMHO.
@aliams: I know you're in favor of excluding path, but I'm in favor of including it. And, unlike what Mozilla nightly does, I think it should be fully qualified. Do you strongly disagree? If so, can we hash this out here?
Do you feel that there is specific reason why we should have it? At TPAC, the consensus was that it would mostly serve as a convenience for developers rather than a necessity. The attribute would be difficult to remove after (for compatibility reasons) so we reasoned that it would be better to not have it there for now and then we can add it back in if there is a demand for it.
@aliams: but what are the compatibility reasons that you mention above that would cause the attribute to be removed, just so I can understand them better? My argument is that it is useful (you don't need to keep track of path as you iterate), that it forces semantic rigor in terms of directory delineation syntax, and that it isn't clear what would motivate it being removed afterwards.
If I could understand why it might be removed, I'd understand why we're afraid of including it.
@aliams: I'm now thinking both Directory and File objects should expose a path property and a name property.
It's true that Directory objects may contain enough stat information (and the web developer can write programs with enough state information about stage of iteration) for path to be deduced, but that's not true of Files, especially if we expose a File flattening function according to WICG/directory-upload#26
In general, this is incredibly convenient and I think it's weird to exclude it. Comments?
@arunranga would you mind taking a look at my comment on issue #26? I think we shouldn't offer a file flattening function until we have AsyncIterators to avoid potentially sub-par user experiences.
AsyncIterators aside, it would still be quite convenient to have the fully qualified path.
