Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(710)

Unified Diff: blimp/net/helium/syncable.h

Issue 2382533002: Helium: Initial proto and Syncable interface definition (Closed)
Patch Set: addressing feedback Created 4 years, 2 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
Index: blimp/net/helium/syncable.h
diff --git a/blimp/net/helium/syncable.h b/blimp/net/helium/syncable.h
new file mode 100644
index 0000000000000000000000000000000000000000..db509cf96913fe3b9d7857cb7cf2f390716e5e73
--- /dev/null
+++ b/blimp/net/helium/syncable.h
@@ -0,0 +1,135 @@
+// Copyright 2016 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 BLIMP_NET_HELIUM_SYNCABLE_H_
+#define BLIMP_NET_HELIUM_SYNCABLE_H_
+
+#include <stdint.h>
+#include <memory>
+
+#include "base/macros.h"
+#include "blimp/common/proto/helium.pb.h"
Kevin M 2016/10/03 22:30:35 Use forward declaration for ChangesetMessage?
scf 2016/10/03 22:52:33 Done.
+#include "blimp/net/helium/vector_clock.h"
+
+namespace blimp {
+
+// Syncable is a base class interface that is used for both SyncableObject and
+// SyncableMember classes.
+//
+// Syncable is something that supports creating and restoring Changesets.
+// Changesets are state that is propagated between client and server to
+// keep corresponding objects eventually synchronized.
+//
+// 1. There is a one-to-one relationship between instances on the client and
Kevin M 2016/10/03 22:30:35 Give this ordered list a quick sentence for contex
scf 2016/10/03 22:52:33 Done.
+// instances on the engine.
+// 2. The values stored in client-engine pairs should eventually be equal.
+//
+// The main difference is that SyncableObject owns its lifetime, whereas
+// SyncableMember depends on its SyncableObject parent.
+//
+// An example for GeoLocation would be:
+// GeoLocation : SyncableObject {
+// * Frequency : SyncableMember
+// * Position : SyncableMember
+// }
+//
+// VectorClocks from a SyncableMember can be compared with the VectorClock from
+// the SyncableObject. This reduces the amount of state that needs to be kept.
+
+template <class ChangesetType>
+class Syncable {
+ public:
+ virtual ~Syncable() {}
+
+ // Constructs a changeset between the |from| revision and its current state.
+ // The Sync layer will encapsulate the changeset with details since |from|,
+ // but the Object is responsible for including any revision information
+ // additional to that expressed by the VectorClocks, that is necessary to
+ // detect and resolve conflicts.
+ // The computed changeset is returned asynchronously as a return parameter.
+ virtual std::unique_ptr<ChangesetType> CreateChangesetToCurrent(
+ const VectorClock& from) = 0;
+
+ // Applies a |changeset| given as parameter to the contents of the
+ // Syncable.
+ // The VectorClocks |from| and |to| can be used to detect and resolve
+ // concurrent change conflicts.
+ virtual void ApplyChangeset(const VectorClock& from,
+ const VectorClock& to,
+ std::unique_ptr<ChangesetType> changeset) = 0;
+
+ // Gives a chance for the Syncable to delete any old data previous to the
+ // |checkpoint|. This is a pretty important method that will remove some
+ // memory pressure for example from the UniqueSet CRDTs. They need to keep
+ // a growing list of added/removed elements over time. With this checkpoint
+ // info they can delete those elements prior to the vector clock specified in
+ // |checkpoint|.
+ virtual void ReleaseCheckpointsBefore(const VectorClock& checkpoint) = 0;
+};
+
+class SyncableObject : public Syncable<helium::ChangesetMessage> {
+ public:
+ explicit SyncableObject(const VectorClock& clock);
+ ~SyncableObject() override {}
+
+ const VectorClock& clock() const { return clock_; }
+
+ VectorClock* mutable_clock() { return &clock_; }
+
+ protected:
+ // The clock is needed in order for the |SyncableMember| objects whenever
+ // they modify their state they update their |last_modified_| value.
+ // The rationale here is use a "global" per SyncableObject clock which makes
+ // state management a lot simpler.
+ VectorClock clock_;
+
+ private:
+ DISALLOW_COPY_AND_ASSIGN(SyncableObject);
+};
+
+template <class ChangesetType>
+class SyncableMember : public Syncable<ChangesetType> {
+ public:
+ explicit SyncableMember(SyncableObject* parent);
+ ~SyncableMember() override {}
+
+ // Returns true if the object have been modified since |from|.
+ virtual bool ModifiedSince(const VectorClock& from) = 0;
+
+ protected:
+ // Increments the parent clock and returns the new value. Should be used
+ // whenever a SyncableMember updates its state.
+ VectorClock IncrementParentClock();
+
+ // Returns the current value of the vector clock of the parent object (aka
+ // SyncableObject).
+ const VectorClock& parent_clock() const;
+
+ private:
+ SyncableObject* parent_;
+ DISALLOW_COPY_AND_ASSIGN(SyncableMember);
+};
+
+// Actual implementations are inline because of template instantiation.
Kevin M 2016/10/03 22:30:35 No need to write this
scf 2016/10/03 22:52:33 Done.
+
+SyncableObject::SyncableObject(const VectorClock& clock) : clock_(clock) {}
+
+template <class ChangesetType>
+SyncableMember<ChangesetType>::SyncableMember(SyncableObject* parent)
+ : parent_(parent) {}
+
+template <class ChangesetType>
+VectorClock SyncableMember<ChangesetType>::IncrementParentClock() {
+ parent_->mutable_clock()->IncrementLocal();
+ return parent_->clock();
+}
+
+template <class ChangesetType>
+const VectorClock& SyncableMember<ChangesetType>::parent_clock() const {
+ return parent_->clock();
+}
+
+} // namespace blimp
+
+#endif // BLIMP_NET_HELIUM_SYNCABLE_H_

Powered by Google App Engine
This is Rietveld 408576698