Consider renaming Entry to something else

[domenic]

E.g. FileOrDirectoryEntry. See blink-dev concerns about the name in global scope

[inexorabletash]

Aside: rename DOMFileSystem to something less grotesque at the same time? I dunno..

[inexorabletash]

... and then drop [NoInterfaceObject] on the types, per inline issue

I'm really hoping to avoid Edge's webkitFileEntry and friends getting baked into the platform, but is there a chance Edge and Gecko will follow suit if Chrome makes this change?

@aliams @smaug---- ?

[smaug----]

FileSystemEntry perhaps? and then drop NoInterfaceObject

[aliams]

I think it's low enough risk to change the names of these interfaces in Edge since they are NoInterfaceObjects in Chrome and Firefox and hence never actually referenced by a web developer in their code.

How do you feel about prefixing these interfaces with something like FileSystem:

• FileSystem
• FileSystemEntry
• FileSystemFileEntry
• FileSystemDirectoryEntry

Alternatively, we can prefix with FS so the interface names aren't as lengthy.

On the other hand, would you prefer that we only change Entry to avoid it's ambiguity as per the blink-dev thread?

[smaug----]

FileSystem prefix with them all sounds good.

[inexorabletash]

HTTPArchive (2016-08-01) turns up:

• 0 hits on FileSystemEntry
• 0 hits on FileSystemFileEntry
• 0 hits on FileSystemDirectoryEntry

.. so I think we're good there!

FileSystem itself has a couple hits as window.FileSystem and var FileSystem (searching for "FileSystem" on its own gets hundreds of hits, since it's such a generic phrase, so I'm ignoring that)

• One use of var FileSystem = ... -this would overwrite the new global and keep working.
• One use of "undefined"!=typeof window.FileSystem as part of a long browser detection scheme (looking for Samsung SmartHub devices); the first part of the test does a string test for a proprietary OS and later look for specific firmware.

Should we ahead with trying DOMFileSystem → FileSystem or just keep that one? (there were 0 hits for window.DOMFileSystem and var DOMFileSystem). Other phrases I should search on?

[annevk]

Not having DOM-prefixes would be nice. I like @aliams' list.

[smaug----]

@inexorabletash so which naming will blink use?
Especially FileSystem or DOMFileSystem?

@bakulf ^

[annevk]

@smaug---- see https://groups.google.com/a/chromium.org/d/msg/blink-dev/xTfeHGlcIQg/X0Q4iDJHAgAJ. The intent specifies FileSystem, but it's not yet approved or tried.

[bakulf]

We should rename DirectoryReader to FileSystemDirectoryReader as well.

[bakulf]

I suggest to rename these callbacks too:

BlobCallback -> FileSystemBlobCallback
EntriesCallback -> FileSystemEntriesCallback
EntryCallback -> FileSystemEntryCallback
ErrorCallback -> FileSystemErrorCallback
VoidCallback -> FileSystemVoidCallback

[smaug----]

Yeah, I think those changes make sense and keep the API more consistent. And the tiny bit long names don't really matter in practice.

[annevk]

Is BlobCallback not in HTML already?

[annevk]

(Callback names are not exposed by the way so their names matter much less, if at all.)

[bakulf]

FileCallback is part of HTMLCanvasElement. BlobCallback doesn't exist yet.
Probably it's OK to keep BlobCallback, ErrorCallback and VoidCallback. But EntriesCallback and EntryCallback should follow the new names.