Add skeleton code to wire Local- and Remote- file sync services

chrome/browser/sync_file_system/remote_change_processor.h

+// Copyright (c) 2012 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 CHROME_BROWSER_SYNC_FILE_SYSTEM_REMOTE_CHANGE_PROCESSOR_H_
+#define CHROME_BROWSER_SYNC_FILE_SYSTEM_REMOTE_CHANGE_PROCESSOR_H_
+
+#include "base/basictypes.h"
+#include "base/callback_forward.h"
+#include "webkit/fileapi/syncable/sync_status_code.h"
+
+class FilePath;
+
+namespace fileapi {
+class FileChange;
+class FileChangeList;
+class FileSystemURL;
+}
+
+namespace sync_file_system {
+
+// Represents an interface to process one remote change and applies
+// it to the local file system.
+// This interface is to be implemented/backed by LocalSyncFileService.
+class RemoteChangeProcessor {
+ public:
+  typedef base::Callback<void(
+      fileapi::SyncStatusCode status,
+      fileapi::FileChangeList& change)> PrepareChangeCallback;
+  typedef base::Callback<void(fileapi::SyncStatusCode status)> StatusCallback;
+
+  RemoteChangeProcessor() {}
+  virtual ~RemoteChangeProcessor() {}
+
+  // This must be called before processing the change for the |url|.
+  // This tries to lock the target |url| and returns the local changes
+  // if any. (The change returned by the callback is to make a decision
+  // on conflict resolution, but NOT for applying local changes to the remote,
+  // which is supposed to be done by LocalChangeProcessor)
+  virtual void PrepareForProcessRemoteChange(
+      const fileapi::FileSystemURL& url,
+      const PrepareChangeCallback& callback) = 0;

[kinuko, 2012/10/22 09:21:06]

The remote sync service will call this method when it is asked by
SyncFileSystemService to perform one remote sync.

* If the current remote change is DELETE and the url is in writing or we have
local changes for the url we can ignore/skip the remote change
* If the current remote change is ADD/DELETE and the url is in writing we will
likely have a conflict; may want to suspend there and return the process back to
the SyncFileSystemService (or we can possibly just record a conflict here though
if the ongoing local change was delete we'll need to remove the conflict mark
later)

Conflict status must be recorded in the remote service as well as to be
propagated to the SyncFileSystemService (via callback).
In the current design we don't need to record the file metadata at this stage.

+
+  // This is called to apply the remote |change|. If the change type is
+  // ADD_OR_UPDATE for a file, |local_path| needs to point to a
+  // local file path that contains the latest file image (e.g. a path
+  // to a temporary file which has the data downloaded from the server).
+  // This may fail with an error but should NOT result in a conflict
+  // (as we must have checked the change status in PrepareRemoteSync and
+  // have disabled any further writing).
+  virtual void ApplyRemoteChange(
+      const fileapi::FileChange& change,
+      const FilePath& local_path,
+      const fileapi::FileSystemURL& url,
+      const StatusCallback& callback) = 0;

[kinuko, 2012/10/22 09:21:06]

The remote sync service will call this method to actually apply the change to
the local side.  If the change was ADD/DELETE it needs to finish downloading the
remote file before calling this.

+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(RemoteChangeProcessor);
+};
+
+}  // namespace sync_file_system
+
+#endif  // CHROME_BROWSER_SYNC_FILE_SYSTEM_REMOTE_CHANGE_PROCESSOR_H_