search

WICG / entries-api

Spec defining browser support for file/directory upload by drag-and-drop
https://wicg.github.io/entries-api/
Other
41 stars 9 forks source link

Consider renaming Entry to something else #6

Closed domenic closed 7 years ago

domenic commented 8 years ago

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

inexorabletash commented 8 years ago

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

inexorabletash commented 8 years ago

... 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---- commented 8 years ago

FileSystemEntry perhaps? and then drop NoInterfaceObject

aliams commented 8 years ago

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:

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---- commented 8 years ago

FileSystem prefix with them all sounds good.

inexorabletash commented 8 years ago

HTTPArchive (2016-08-01) turns up:

.. 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)

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 commented 8 years ago

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

smaug---- commented 8 years ago

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

@bakulf ^

annevk commented 8 years ago

@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 commented 8 years ago

We should rename DirectoryReader to FileSystemDirectoryReader as well.

bakulf commented 8 years ago

I suggest to rename these callbacks too:

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

smaug---- commented 8 years ago

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 commented 8 years ago

Is BlobCallback not in HTML already?

annevk commented 8 years ago

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

bakulf commented 8 years ago

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.

inexorabletash commented 8 years ago

Change was approved for Blink. I'm travelling so it'll be a couple days before I can make the change and update the spec.

I agree with @bakulf's last comment, and will rename the FileSystemEntry/Entries callbacks as well for spec consistency in case plain "Entry" does make it into another spec in the future.

inexorabletash commented 8 years ago

I don't suppose anyone wants to review https://github.com/WICG/entries-api/pull/8 ?

smaug---- commented 8 years ago

@bakulf could you check if ^ matches your patch, in other words review the change here.

inexorabletash commented 7 years ago

Note that it may take some time for Blink to make the change since there are lots of internal dependencies c/o the use of the same types for the Chrome-only FileSystem API. Worst case we can "fork" our impl for the Directory Upload use case vs. File System case. But that's an impl issue, so resolving here.

bakulf commented 7 years ago

@smaug---- , yes this is what we have in gecko.