[fsp] Add requestUnmount() method together with the request manager.

chrome/common/extensions/api/file_system_provider.idl

Index: chrome/common/extensions/api/file_system_provider.idl
diff --git a/chrome/common/extensions/api/file_system_provider.idl b/chrome/common/extensions/api/file_system_provider.idl
index 173a1c8c2d806be7fb81ee04217d1c7b023438b0..b55b0c258d23946a8a201cc0f9c76be181ff152f 100644
--- a/chrome/common/extensions/api/file_system_provider.idl
+++ b/chrome/common/extensions/api/file_system_provider.idl
@@ -7,6 +7,29 @@
 [platforms=("chromeos"),
  implemented_in="chrome/browser/chromeos/extensions/file_system_provider/file_system_provider_api.h"]
 namespace fileSystemProvider {
+  // Error codes, same as in base::Files::Error. Note, that DOMError would be

[benwells, 2014/03/30 22:37:07]

This note doesn't seem right for public documentation.

[mtomasz, 2014/03/31 01:01:47]

Done.

+  // preferred, but currently there is no easy way to create DOMError instances
+  // in JavaScript.
+  enum ProviderError {
+    OK,
+    FAILED,
+    IN_USE,
+    EXISTS,
+    NOT_FOUND,
+    ACCESS_DENIED,
+    TOO_MANY_OPENED,
+    NO_MEMORY,
+    NO_SPACE,
+    NOT_A_DIRECTORY,
+    INVALID_OPERATION,
+    SECURITY,
+    ABORT,
+    NOT_A_FILE,
+    NOT_EMPTY,
+    INVALID_URL,
+    IO
+  };
+
   // Callback to receive the result of mount() function.
   // <code>fileSystemID</code> will be a unique ID for the file system just
   // mounted. The ID is used to distinguish multiple file systems mounted
@@ -14,6 +37,18 @@ namespace fileSystemProvider {
   callback MountCallback = void(long fileSystemId,
                                 [nodoc, instanceOf=DOMError] object error);
 
+
+  // Callback to receive the result of unmount() function with the <code>
+  // fileSystemId</code> identifier.
+  callback UnmountCallback = void(long fileSystemId,
+                                  [nodoc, instanceOf=DOMError] object error);

[benwells, 2014/03/30 22:37:07]

Why is the error nodoc?

[mtomasz, 2014/03/31 01:01:47]

Done.

[mtomasz, 2014/03/31 01:01:47]

Copy pasted. Removed. Done.

[mtomasz, 2014/03/31 01:08:53]

Actually, there is a reason. Error is passed via the error callback. See #63.
The |error| argument is forwarded to ErroCallback (declared in #53).

This trick is used to be able to have two callbacks (success and error), and it
has been discussed in https://codereview.chromium.org/50703013.

+
+  // Callback to be called by the providing extension in case of a success.
+  callback ProviderSuccessCallback = void();
+
+  // Callback to be called by the providing extension in case of an error.
+  callback ProviderErrorCallback = void(ProviderError error);
+
   // Callback to handle an error raised from the browser.
   [nocompile] callback ErrorCallback = void([instanceOf=DOMError] object error);
 
@@ -22,10 +57,33 @@ namespace fileSystemProvider {
     // <code>displayName</code> will be shown in the left panel of
     // Files.app. <code>displayName</code> can contain any characters
     // including '/', but cannot be an empty string. <code>displayName</code>
-    // should be descritive but doesn't have to be unique. Duplicate display
+    // should be descriptive but doesn't have to be unique. Duplicate display
     // names are uniquified by adding suffix like "(1)" in the Files.app UI.
     static void mount(DOMString displayName,
                       MountCallback successCallback,
                       [nocompile] ErrorCallback errorCallback);
+
+    // Unmounts a file system with the given <code>fileSystemId</code>. It
+    // should be called after <code>onUnmountRequested</code> is invoked. Also,
+    // the providing extension can decide to perform unmounting if not requested
+    // (eg. in case of lost connection, or a file error). If there is no file
+    // system with the requested id, or unmounting fails, then the
+    // <code>errorCallback</code> will be called.
+    static void unmount(long fileSystemId,
+                        UnmountCallback successCallback,
+                        [nocompile] ErrorCallback errorCallback);
+  };
+
+  interface Events {
+    // Raised, when the user requests unmounting of the file system with the
+    // <code>fileSystemId</code> identifier in the Files.app UI. In response,
+    // the <code>unmount</code> API method should be called. If unmounting is
+    // not possible (eg. due to pending operation), then <code>errorCallback
+    // </code> should be called, and <code>unmount</code> should not be called.
+    [maxListeners=1] static void onUnmountRequested(
+        long fileSystemId,
+        ProviderSuccessCallback successCallback,
+        ProviderErrorCallback errorCallback);

[benwells, 2014/03/30 22:37:07]

What happens if a provider is uncooperative and doesn't play ball? E.g. they
don't unmount, or they don't call either successCallback ro errorCallback?

[mtomasz, 2014/03/31 01:01:47]

Then the request will never be completed. I'm aware of it, and there is a plan
to implement a timeout for requests soon. It is mentioned in the API design doc.

   };
 };
+