Add FileSystemMountPointProvider::CreateFileReader() which returns appropriate Reader instance

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 fa8ca133836ba08b2395bd8d864e83b05d0207dc..18e1d9ab2973d7fbc4d954073a46800a08dc24da 100644
--- a/webkit/fileapi/file_system_mount_point_provider.h
+++ b/webkit/fileapi/file_system_mount_point_provider.h
@@ -20,6 +20,10 @@ namespace base {
 class MessageLoopProxy;
 }
 
+namespace webkit_blob {
+class FileReader;
+}
+
 namespace fileapi {
 
 class FileSystemContext;
@@ -90,6 +94,17 @@ class FileSystemMountPointProvider {
       const FilePath& virtual_path,
       base::MessageLoopProxy* file_proxy,
       FileSystemContext* context) const = 0;
+
+  // Creates a new file reader for a given filesystem URL |url| with a offset
+  // |offset|.
+  // The returned object must be owned and managed by the caller.
+  // This method itself does *not* check if the given path exists and is a
+  // regular file.
+  virtual webkit_blob::FileReader* CreateFileReader(

[michaeln, 2012/04/13 21:53:51]

Would it make sense to have the MPP::CreateFileReader() method take the same
cracked components as  MPP::CreateFSO() method? They seem similar in nature and
it makes we want to keep the inputs in parallel.

Oh... I see... FileSystemFileReader's ctor wants a url under the covers here.

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