Hi Mike, Good question!
To explain it a different way... why do we need an isSameEntry() method? Why can't we just compare two FileSystemHandle objects directly? Well, a handle mostly just represents a path on disk (which we never want to expose to a site). The API has a number of ways (drag & drop, file picker, file handling, re-hydration from IndexedDB) to acquire a handle. Two handles acquired from different contexts (possibly at various times, across browsing sessions) may represent the same path and should be considered equal. Only the browser knows where this file actually lives on disk, so only it can determine equality. We essentially have the same problem here. We can create a unique ID using crypto.randomUUID(), but if we want it to represent the idea of a path on disk and not just a one-way mapping to an arbitrary FileSystemHandle object, we need the browser's help (or to call isSameEntry() on an unbounded number of handles (yikes)). To make this a bit more concrete, let's consider an example from the *Storing a representation of a handle in the database of your choice* use case described in the explainer. Say you're a site which allows users to maintain a digital database of their baseball cards <https://en.wikipedia.org/wiki/Baseball_card>. The user selects an image file of the card. You generate an ID using crypto.randomUUID() which represents the file to use as a key in your database alongside all the card's information. You can access the handle using this key with a constant-time lookup in IndexedDB. A week later, the user logs back on and selects a file from the picker. Is this card already in the database? Your only way to find out is to enumerate all handles you have access to (which could be thousands and thousands of cards) and call isSameEntry() on each of them. The ID you generated is useless until you find the handle in IndexedDB (i.e. handle -> database is potentially a prohibitively expensive operation). The getUniqueId() method addresses this by answering the "have I seen this handle before" question in constant time. On Tue, Aug 16, 2022 at 1:07 AM Mike West <mk...@chromium.org> wrote: > Hi! I've skimmed through the explainer, but I feel like I'm missing > something important. Can you help me understand the difference between the > scheme proposed here on the one hand, and relying on something like > Crypto.randomUUID() > <https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID> on > the other? I don't understand the requirements that would make the latter > unworkable, but I'd like to before we add another identifier-generator to > the platform. :) > > Thanks! > > -mike > > On Friday, August 12, 2022 at 7:15:58 PM UTC+2 Austin Sullivan wrote: > >> Contact emailsasu...@chromium.org >> >> Specificationhttps://github.com/whatwg/fs/pull/46 >> >> Summary >> >> FileSystemHandle::getUniqueId() generates a uniquely identifying string >> which can be used as a key, such as for IndexedDB or WebLocks. Currently, >> FileSystemHandle objects can be serialized by the browser to be stored as >> values in IndexedDB, but there is no way to generate a string which is >> guaranteed to be uniquely identifying. >> >> >> Developers have complained that building rich experiences on top of the >> File System Access API is challenging due to the inability to uniquely >> identify (and index on) handles. Several partners have requested this. >> >> >> Blink componentBlink>Storage>FileSystem >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileSystem> >> >> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/764 >> >> TAG review statusPending >> >> Risks >> >> >> Interoperability and Compatibility >> >> >> >> *Gecko*: No signal >> >> *WebKit*: No signal >> >> *Web developers*: Positive ( >> https://github.com/WICG/file-system-access/issues/295) >> >> *Other signals*: >> >> Debuggability >> >> N/A >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, Chrome OS, Android, and Android WebView)?This feature will be >> supported on all platforms https://github.com/whatwg/fs/ is shipped >> (currently only desktop platforms) >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> The feature will be fully testable with WPT. They'll be written as part >> of the prototype >> >> Flag nameFileSystemAccessAPIExperimental >> >> Tracking bughttps://crbug.com/1342961 >> >> Estimated milestones >> >> No milestones specified >> >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5190893263388672 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnvaEWKws3C%2BeUOMMG4bcno-HLN1CVuOOQ5zRxKAKdDasBOaw%40mail.gmail.com.
