Add the FileSystemObserver API#165
Conversation
Gives each concept in the concepts section its own section.
Pulls out some implementation-defined concepts into a file system concept. This is so that the file system concept can be extended further in the future.
Pulls out some implementation-defined concepts into a file system concept. This is so that the file system concept can be extended further in the future.
Defines the FileSystemObserver API, an API to observe file system change events. See whatwg#123 and WICG/file-system-access#72
nathanmemmott
force-pushed
the
file_system_observer
branch
from
320d58a
to
8047a41
Compare
| 1. [=file system observation/Destroy observation=] |observation|. | ||
| 1. [=break=]. | ||
|
|
||
| 1. [=file system observation/Invoke the callback=] of the |observation| with |
There was a problem hiding this comment.
If records is empty, invoke should not be called.
There was a problem hiding this comment.
It would be nice if we could somehow specify more precisely what exact change events are triggered by changes to the bucket file system, since that should be entirely under control of user agents, so should be possible to be fully compatible between implementations. Not sure how to be go about doing that. Left a bunch of other comments as well...
|
|
||
| A <dfn export>file system</dfn> is an [=implementation-defined=] | ||
| [=storage endpoint=] that maintains a mapping of [=file system path=]s to | ||
| [=file system entry|file system entries=]. |
There was a problem hiding this comment.
nit: bikeshed is generally clever enough to figure out that [=file system entries=] should link to file system entry without having to spell it out.
| 1. Set |eventEntryType| to |observationLocator|'s [=file system locator/kind=]. | ||
|
|
||
| Note: When we don't know the {{FileSystemHandleKind}} of the | ||
| [=file system/file system event/modified path=], we must arbitrarily choose |
There was a problem hiding this comment.
nit: prefer not to use "must" in non-normative text as it imp. "have to" might be better (see https://infra.spec.whatwg.org/#conformance)
| a [=/file system path=] |b| if | ||
| |a|'s [=list/size=] is the same as |b|'s [=list/size=] and | ||
| [=list/for each=] |index| of |a|'s [=list/indices=] | ||
| |a|.\[[|index|]] is |b|.\[[|index|]]. |
There was a problem hiding this comment.
optional nit: you could link to [=string/is=] to make it explicit what kind of string comparison this uses, although I guess the "Except where otherwise stated, all string comparisons use is." comment from infra kind of implies that anyway.
| - |entry|'s [=file system entry/name=] is the last [=list/item=] of |path|. | ||
|
|
||
| </div> | ||
| Each [=/file system=] generates <dfn for="file system">file system event</dfn>s |
There was a problem hiding this comment.
This doesn't quite feel like a normative thing. Especially since this doesn't really define what "generate" or "modify its state" mean here. Would it make sense to instead have something like "A <dfn>file system event</dfn> is a [=struct=] consisting of ..." followed by a non-normative note with more or less this sentence instead?
| an <dfn for="file system/file system event">entry type</dfn> (a {{FileSystemHandleKind}} or null), | ||
| a [=/file system path=] <dfn for="file system/file system event">modified path</dfn>, | ||
| and a <dfn for="file system/file system event">from path</dfn> (a [=/file system path=] or null). | ||
| The [=file system/file system event/from path=] must be set for when |
There was a problem hiding this comment.
nit: "must be set when"?
|
|
||
| 1. Let |result| be [=a new promise=]. | ||
| 1. [=Enqueue the following steps=] to the [=file system queue=]: | ||
| 1. [=/resolve=] |result| with the result of [=file system locator/resolving=] |
There was a problem hiding this comment.
You can't call "/resolve" on a parallel queue. You need to post a task back to the correct event loop to resolve the actual promise.
| ### File System ### {#concept-file-system} | ||
|
|
||
| A <dfn export>file system</dfn> is an [=implementation-defined=] | ||
| [=storage endpoint=] that maintains a mapping of [=file system path=]s to |
There was a problem hiding this comment.
I don't think it makes sense for a "file system" to be a storage endpoint. A storage endpoint is defined as "an API" after all. The bucket file system somehow should still be a storage endpoint, but a generic file system concept here I don't think should have anything to do with a "storage endpoint".
| }; | ||
| </xmp> | ||
|
|
||
| The {{FileSystemObserver}} interface can be used to observe |
There was a problem hiding this comment.
nit: this should possibly be a non-normative ("for developers") note
| Exposed=(DedicatedWorker,SharedWorker,Window), | ||
| SecureContext, | ||
| RuntimeEnabled=FileSystemObserver | ||
| ] interface FileSystemChangeRecord { |
There was a problem hiding this comment.
I wonder why this is an interface? It seems this could just as well be a dictionary, which might make some things simpler? If this does have to be an interface for some reason, it at least needs a constructor per https://www.w3.org/TR/design-principles/#constructors.
| :: The path of `changedHandle` relative to `root`. | ||
| : <dfn>type</dfn> | ||
| :: The type of change. | ||
| : <dfn>relativePathMovedFrom</dfn> |
There was a problem hiding this comment.
nit: add a definition for relativePathComponents as well? Although all these read more like non-normative web developer documentation (which is also good to have) rather than normative definitions.
Add the FileSystemObserver API
Defines the FileSystemObserver API, an API to observe file system
change events.
See #123 and WICG/file-system-access#72
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff