Implement async verision of FileSystemFileUtil and in-memory file system for testing purposes.

webkit/chromeos/fileapi/file_util_async.h

Index: webkit/chromeos/fileapi/file_util_async.h
diff --git a/webkit/chromeos/fileapi/file_util_async.h b/webkit/chromeos/fileapi/file_util_async.h
new file mode 100644
index 0000000000000000000000000000000000000000..a768d57ad7b71560c854b4bffbd63b38b755ee9b
--- /dev/null
+++ b/webkit/chromeos/fileapi/file_util_async.h
@@ -0,0 +1,154 @@
+// Copyright (c) 2011 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.
+
+#ifndef WEBKIT_CHROMEOS_FILEAPI_FILE_SYSTEM_FILE_UTIL_ASYNC_H_
+#define WEBKIT_CHROMEOS_FILEAPI_FILE_SYSTEM_FILE_UTIL_ASYNC_H_
+
+#include "base/callback.h"
+#include "base/file_util_proxy.h"
+#include "base/platform_file.h"
+#include "webkit/chromeos/fileapi/async_file_stream.h"
+
+namespace fileapi {
+
+using base::PlatformFileError;
+
+// The implementation of this base class should override all the pure virtual
+// methods and one of the following 3 choices:
+// - Read() & Write()
+// - OpenVerifiedFile()
+// - Open()
+// Read() & Write() are the easiest to implement, but in that case
+// the FileUtilAsync implementation does not have any "opened file" entity.
+// OpenVerifiedFile() will allow to overload FileSystemAsyncFileStream, making
+// it possible to hold some handle for an open file, like PlatformFile*.
+// Open() is the same as OpenVerifiedFile(), but in its case the implementation
+// is responsible for all the checks. It is preferrable in the case of remote
+// operation when it is possible to batch several checks into one query.

[satorux1, 2011/12/14 05:19:55]

Discussed this with Kinuko. She suggested providing three options here was not a
good idea, and I agreed per the philosophy of YAGNI (see wikipedia). Providing
options here will bloat the code, and make it hard to maintain and test code. We
can add options at a later time when really needed. Let me simplify the code a
bit.

[Oleg Eterevsky, 2011/12/14 15:20:59]

In that case I suggest to move OpenVerifiedFile from protected to private and
make Open non-virtual. I suggest leaving only stateless protected Read & Write
to be overridden by the implementations (as it is done in MemoryFileUtil).

[satorux1, 2011/12/15 00:32:00]

Kinuko and I found it awkward to implement Read() and Write() in the class.
That's why we chose to remove them. See below.

+class FileUtilAsync {
+ public:
+  typedef base::FileUtilProxy::Entry DirectoryEntry;
+
+  typedef base::Callback<void(
+      PlatformFileError,
+      const base::PlatformFileInfo&)> GetFileInfoCallback;
+
+  // AsyncFileStream is reference-counted.
+  typedef base::Callback<void(
+      PlatformFileError,
+      AsyncFileStream*)> OpenCallback;
+
+  typedef std::vector<DirectoryEntry> FileList;
+
+  typedef base::Callback<void(
+      PlatformFileError error,
+      const FileList& file_list,
+      // True if completed.
+      bool success)> ReadDirectoryCallback;
+
+  virtual void GetFileInfo(
+      const FilePath& file_path,
+      const GetFileInfoCallback& callback) = 0;
+
+  virtual void Create(
+      const FilePath& file_path,
+      const StatusCallback& callback) = 0;
+
+  virtual void Truncate(
+      const FilePath& file_path,
+      int64 length,
+      const StatusCallback& callback) = 0;
+
+  virtual void Touch(
+      const FilePath& file_path,
+      const base::Time& last_access_time,
+      const base::Time& last_modified_time,
+      const StatusCallback& callback) = 0;
+
+  virtual void Remove(
+      const FilePath& file_path,
+      bool recursive,
+      const StatusCallback& callback) = 0;
+
+  virtual void Open(
+      const FilePath& file_path,
+      int file_flags,  // PlatformFileFlags
+      const OpenCallback& callback);
+
+  virtual void CreateDirectory(
+      const FilePath& dir_path,
+      const StatusCallback& callback) = 0;
+
+  // The ReadDirectoryCallback may be called several times, returning the
+  // portions of the whole directory listing. The reference to vector with
+  // DirectoryEntry objects, passed to callback is guaranteed to contain the
+  // reults of the operation only while callback is running.
+  //
+  // The implementations of FileUtilAsync should be careful to populate the
+  // vector on the same thread, on which the callback is called. Otherwise,
+  // if callback is called through PostTask, the data might get overwritten
+  // before callback is actually called.
+  //
+  // TODO(olege): Maybe make it possible to read only a part of the directory.
+  virtual void ReadDirectory(
+      const FilePath& dir_path,
+      const ReadDirectoryCallback& callback) = 0;
+
+  // TODO(olege): Add LocalCopy and LocalMove.
+
+ protected:
+  FileUtilAsync();
+
+  virtual void Write(
+      const FilePath& file_path,
+      int64 offset,
+      const char* data,
+      int64 length,
+      const ReadWriteCallback& callback) {
+    NOTREACHED();
+  }
+
+  virtual void Read(
+      const FilePath& file_path,
+      int64 offset,
+      char* buffer,
+      int64 length,
+      const ReadWriteCallback& callback) {
+    NOTREACHED();
+  }

[satorux1, 2011/12/14 05:19:55]

Discussed this with kinuko. Providing Read() and Write() here looks wrong. These
operations can be done using AsyncFileStream object. Providing two ways to do
the same thing is not great for the same reason described above.

[Oleg Eterevsky, 2011/12/14 15:20:59]

These Read() and Write() allow the implementation not to create their versions
of AsyncFileStream, but to perform these operations statelesly. It allows
reusing quite a bit of code (AsyncFileStream takes more than 150 lines).

[satorux1, 2011/12/15 00:32:00]

Read and write operations are inherently associated with file streams. 
Implementing them statelessly here looked awkward.

Besides, Kinuko and I agreed that interaction between FileUtilAsyncFileStream
and FileUtilAsync in the original patch was the most convoluted part in the
orignal patch, and we were able to remove FileUtilAsyncFileStream by removing
Read() and Write() from this class.

+
+  virtual void OpenVerifiedFile(
+      const FilePath& file_path,
+      int flags,
+      const OpenCallback& callback);
+
+ private:
+  friend class FileUtilAsyncFileStream;
+
+  void DidGetFileInfoForOpen(
+      const FilePath& file_path,
+      int flags,
+      const OpenCallback& callback,
+      PlatformFileError get_info_res,
+      const base::PlatformFileInfo& file_info);
+
+  void OpenTruncatedFileOrCreate(
+      const FilePath& file_path,
+      int flags,
+      const OpenCallback& callback,
+      PlatformFileError res);
+
+  void DidCreateOrTruncateForOpen(
+      const FilePath& file_path,
+      int flags,
+      int64 size,
+      const OpenCallback& callback,
+      PlatformFileError res);
+
+  DISALLOW_COPY_AND_ASSIGN(FileUtilAsync);
+};
+
+}
+
+#endif  // WEBKIT_CHROMEOS_FILEAPI_FILE_SYSTEM_FILE_UTIL_ASYNC_H_