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

webkit/chromeos/fileapi/async_file_stream.h

+// 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_FILEAPI_ASYNC_FILE_STREAM_H_
+#define WEBKIT_FILEAPI_ASYNC_FILE_STREAM_H_

[kinuko, 2011/12/14 03:39:22]

nit: needs to be updated as well (to add CHROMEOS_)

[satorux1, 2011/12/14 04:43:26]

Done.

+
+#include "base/platform_file.h"
+#include "base/callback.h"
+
+namespace fileapi {
+
+using base::PlatformFileError;
+
+typedef base::Callback<void(PlatformFileError, int64)> ReadWriteCallback;
+typedef base::Callback<void(PlatformFileError)> StatusCallback;
+
+// Abstract class similar to net::FileStream, but supporting only
+// the asyncronous operations and not necessarily relying on PlatformFile.
+class AsyncFileStream {
+ public:
+  virtual ~AsyncFileStream() {};
+
+  virtual void Read(char* buffer,
+                    int64 length,
+                    const ReadWriteCallback& callback) = 0;

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

The API looks error-prone. The caller needs to maintain |buffer| to remain valid
until |callback| is called. FileStream in 'net' is designed this way, as it's
used both synchronously and asynchronously. Here, we only need to support
asynchronous reads, so we could provide a better API for this. Let me give it a
try.

[satorux1, 2011/12/14 06:55:17]

I take it back. We could design an API that does not require the caller to keep
the pointer valid, but it'll likely require an extra data copy, which is not
desirable here.

+
+  virtual void Write(const char* buffer,
+                     int64 length,
+                     const ReadWriteCallback& callback) = 0;
+
+  virtual void Seek(int64 offset,
+                    const StatusCallback& callback) = 0;
+};
+
+}  // namespace fileapi
+
+#endif  // WEBKIT_FILEAPI_ASYNC_FILE_STREAM_H_