sync: SyncableService support for starting sync

sync/api/syncable_service.h

 // Copyright 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 SYNC_API_SYNCABLE_SERVICE_H_
 #define SYNC_API_SYNCABLE_SERVICE_H_
 
 #include <vector>
 
+#include "base/callback.h"
 #include "base/compiler_specific.h"
 #include "base/memory/scoped_ptr.h"
 #include "base/memory/weak_ptr.h"
 #include "sync/api/sync_change_processor.h"
 #include "sync/api/sync_data.h"
 #include "sync/api/sync_error.h"
 #include "sync/api/sync_merge_result.h"
 #include "sync/base/sync_export.h"
 #include "sync/internal_api/public/base/model_type.h"
 
 namespace syncer {
 
 class SyncErrorFactory;
 
+// Used as a parameter to InjectStartSyncFlare. The StartSyncFlare is useful
+// when your SyncableService has a need for sync to start ASAP, typically
+// because a local change event has occurred but MergeDataAndStartSyncing
+// hasn't been called yet, meaning you don't have a SyncChangeProcessor.
+// The sync subsystem will respond soon after invoking Run() on your flare
+// by calling MergeDataAndStartSyncing. The ModelType parameter is included so
+// that the recieving end can track usage and timing statistics, make
+// optimizations or tradeoffs by type, etc.
+typedef base::Callback<void(ModelType)> StartSyncFlare;
+
 // TODO(zea): remove SupportsWeakPtr in favor of having all SyncableService
 // implementers provide a way of getting a weak pointer to themselves.
 // See crbug.com/100114.
 class SYNC_EXPORT SyncableService
     : public SyncChangeProcessor,
       public base::SupportsWeakPtr<SyncableService> {
  public:
+  // Provides a StartSyncFlare to the SyncableService.
+  // TODO(tim): BUG 80194. Make pure virtual.
+  virtual void InjectStartSyncFlare(const StartSyncFlare& flare);

[Nicolas Zea, 2013/05/01 22:37:04]

Is this really necessary? Why can't a datatype just include start_sync_until,
build a flare, and call it directly?

[tim (not reviewing), 2013/05/01 23:20:44]

Is there an elegant way to get a hold of a profile or profile path from backend
SyncableServices or would they all wind up having to have that passed in as a
parameter anyway, in which case I was thinking I'd rather pass the more specific
thing it actually needs.

[Nicolas Zea, 2013/05/02 18:01:07]

I'm fine with passing the more specific thing, i.e. the callback, but it just
doesn't seem like InjectStartSyncFlare needs to be part of the SyncableService
api.

The WebDataFactory already knows about the AutocompleteSyncableService, and I'd
imagine any other datatype specific factories/objects would be able to pass the
callback through without needing to use the SyncableService interface.

+
   // Informs the service to begin syncing the specified synced datatype |type|.
   // The service should then merge |initial_sync_data| into it's local data,
   // calling |sync_processor|'s ProcessSyncChanges as necessary to reconcile the
   // two. After this, the SyncableService's local data should match the server
   // data, and the service should be ready to receive and process any further
   // SyncChange's as they occur.
   // Returns: a SyncMergeResult whose error field reflects whether an error
   //          was encountered while merging the two models. The merge result
   //          may also contain optional merge statistics.
   virtual SyncMergeResult MergeDataAndStartSyncing(
@@ skipping 19 matching lines @@
       const tracked_objects::Location& from_here,
       const SyncChangeList& change_list) OVERRIDE = 0;
 
  protected:
   virtual ~SyncableService();
 };
 
 }  // namespace syncer
 
 #endif  // SYNC_API_SYNCABLE_SERVICE_H_