gdata: Add requestDirectoryRefresh to file_browser_private.

chrome/common/extensions/api/file_browser_private.json

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 [
   {
     "namespace":"fileBrowserPrivate",
     "nodoc": "true",
     "types": [
       {
@@ skipping 914 matching lines @@
                 "name": "result",
                 "type": "object",
                 "properties": {
                   "type": {"type": "string"},
                   "online": {"type": "boolean"}
                 }
               }
             ]
           }
         ]
+      },
+      {
+        "name": "requestDirectoryRefresh",
+        "description": "Requests a refresh of a directory. Used to get the latest metadata of files in a particular directory. Upon completion, onFileChanged event is raised.",

[asargent_no_longer_on_chrome, 2012/05/18 23:22:34]

Does onFileChanged fire even if the item at |fileURL| actually didn't change?
Also, since this is a directory, should the caller expect to potentially see
onFileChanged fire for any of the files within that directory and its
subdirectories? If so will those fire before or after the onFileChanged for the
directory itself?

BTW, if you're really just interested in giving callers a way to know when
requestDirectoryRefresh has finished some async work in the browser process, you
can declare this to have a no-parameter callback and make its c++ implementation
in the browser process inherit from AsyncExtensionFunction and wait to call
SendResponse once the refresh is complete. 

Then callers in js can do:

chrome.fileBrowserPrivate.requestDirectoryRefresh(
    myurl, function() {
  console.log("directory refresh complete!");
});

[satorux1, 2012/05/18 23:42:19]

Thank you for the suggestion. I thought that notifying the completion via the
existing onFileChanged event was simpler, but now I think it's rather dirty. I'm
going to rework the patch and add ad no-parameter callback.

[satorux1, 2012/05/19 00:09:19]

I played with the new idea, but I changed my mind again. If the contents in the
directory are changed, it's natural to raise onFileChanged() event against the
target directory. If so, notifying the completion via the non-parameter callback
is redundant.

So I kept the API as-is, but added more comments about the semantics.

+        "parameters": [
+          {
+            "name": "fileURL",
+            "type": "string",
+            "description": "URL of the target directory"
+          }
+        ]
       }
     ],
     "events": [
       {
         "name": "onDiskChanged",
         "type": "function",
         "description": "Fired when disk mount/unmount event is detected.",
         "parameters": [
           {
             "$ref": "MountEvent",
@@ skipping 59 matching lines @@
       },
       {
         "name": "onNetworkConnectionChanged",
         "type": "function",
         "description": "Fired when the active network connection state changes. The network connection state can be retrieved via 'getNetworkConnectionState'.",
         "parameters": []
       }
     ]
   }
 ]