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

Add FileSystemContext::CreateFileReader() which returns appropriate Reader instance by cracking a given filesystem URL.

In a short term a returned reader is to be used by FileSystemURLRequestJob and generalized cross-filesystem operation implementation.

For now in most cases it just returns a default FileSystemFileReader which internally calls CreateSnapshotFile (i.e. downloads everything first).

(diff to http://codereview.chromium.org/10038019/)

BUG=114999
TEST=FileSystemURLRequestJobTest.*

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=132957

[kinuko, 2012-04-13 11:33:39]

I'd like to add CreateFileReader interface to FileSystemMountPointProvider as a
step to support Reader stream interface in FileSystem API backend. Could you
take a look?

[michaeln, 2012-04-13 21:53:50]

lgtm

https://chromiumcodereview.appspot.com/10082002/diff/2001/webkit/fileapi/file...
File webkit/fileapi/file_system_mount_point_provider.h (right):

https://chromiumcodereview.appspot.com/10082002/diff/2001/webkit/fileapi/file...
webkit/fileapi/file_system_mount_point_provider.h:103: virtual
webkit_blob::FileReader* CreateFileReader(
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.

[zel, 2012-04-13 22:56:56]

LGTM

http://codereview.chromium.org/10082002/diff/2001/webkit/chromeos/fileapi/cro...
File webkit/chromeos/fileapi/cros_mount_point_provider.cc (right):

http://codereview.chromium.org/10082002/diff/2001/webkit/chromeos/fileapi/cro...
webkit/chromeos/fileapi/cros_mount_point_provider.cc:259:
base::MessageLoopProxy* file_proxy,
are you guys planning to get rid of file_proxy business and go with IO blocking
thread pool instead?

[michaeln, 2012-04-14 00:19:48]

Based on some code comments in there, i think that's what kinuko has in mind. An
option could be to retrofit base::FileUtilProxy to take a TaskRunner instead of
a MessageLoopProxy. Since MLP isa TR, existing callers would be unaffected, but
new callers could schedule their FileUtilProxy  work on the SequencedWorkerPool
too.

> are you guys planning to get rid of file_proxy business and go with IO
blocking
> thread pool instead?

[kinuko, 2012-04-16 03:21:23]

On 2012/04/13 22:56:56, zel wrote:
> LGTM
> 
>
http://codereview.chromium.org/10082002/diff/2001/webkit/chromeos/fileapi/cro...
> File webkit/chromeos/fileapi/cros_mount_point_provider.cc (right):
> 
>
http://codereview.chromium.org/10082002/diff/2001/webkit/chromeos/fileapi/cro...
> webkit/chromeos/fileapi/cros_mount_point_provider.cc:259:
> base::MessageLoopProxy* file_proxy,
> are you guys planning to get rid of file_proxy business and go with IO
blocking
> thread pool instead?

Yes we're planning to do so. How to change existing code in which order was one
of the issue but michael's suggestion sounds good-- we'll work on that will fix
this interface asap.

[commit-bot: I haz the power, 2012-04-19 04:10:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/kinuko@chromium.org/10082002/13001

[commit-bot: I haz the power, 2012-04-19 05:40:21]

Change committed as 132957