Add CreateFileSystemOperation() method to FileSystemContext

webkit/fileapi/file_system_mount_point_provider.h

Index: webkit/fileapi/file_system_mount_point_provider.h
diff --git a/webkit/fileapi/file_system_mount_point_provider.h b/webkit/fileapi/file_system_mount_point_provider.h
index 7d9974c1d635f7a278070db9eece59f6af7bf5ad..9778ca199a82724a8bb7cd8d8515e45b7347c43d 100644
--- a/webkit/fileapi/file_system_mount_point_provider.h
+++ b/webkit/fileapi/file_system_mount_point_provider.h
@@ -15,9 +15,16 @@
 
 class GURL;
 
+namespace base {
+class MessageLoopProxy;
+}
+
 namespace fileapi {
 
+class FileSystemCallbackDispatcher;
+class FileSystemContext;
 class FileSystemFileUtil;
+class FileSystemOperationInterface;
 
 // An interface to provide mount-point-specific path-related utilities
 // and specialized FileSystemFileUtil instance.
@@ -65,6 +72,14 @@ class FileSystemMountPointProvider {
 
   // Returns the specialized FileSystemFileUtil for this mount point.
   virtual FileSystemFileUtil* GetFileUtil() = 0;
+
+  // Returns a new instance of the specialized FileSystemOperation for this
+  // mount point based on the given |url|.
+  virtual FileSystemOperationInterface* CreateFileSystemOperation(

[satorux1, 2011/12/27 20:55:34]

There is also FileSystemContext::CreateFileSystemOperation() with a similar
signature. Why do we need the two functions?

Please add comment to the two functions explaining the differences, and why we
need them.

[kinuko, 2012/01/13 08:28:35]

Added some comments why we have both.  We can get rid of
FileSystemContext::CreateFileSystemOperation as it's just a dispatching layer
but it'll add 4-5 more lines at each callsite, and I thought it might not be
really desirable either.  (Open to objections though)

+      const GURL& url,
+      FileSystemCallbackDispatcher* dispatcher,
+      base::MessageLoopProxy* file_proxy,
+      FileSystemContext* context) const = 0;
 };
 
 // An interface to control external file system access permissions.