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

Side by Side Diff: blimp/net/helium/syncable.h

Issue 2382533002: Helium: Initial proto and Syncable interface definition (Closed)
Patch Set: updating with 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 unified diff | Download patch
OLDNEW
(Empty)
1 // Copyright 2016 The Chromium Authors. All rights reserved.
2 // Use of this source code is governed by a BSD-style license that can be
3 // found in the LICENSE file.
4
5 #ifndef BLIMP_NET_HELIUM_SYNCABLE_H_
6 #define BLIMP_NET_HELIUM_SYNCABLE_H_
7
8 #include <stdint.h>
9 #include <memory>
10
11 #include "base/macros.h"
12 #include "blimp/net/helium/vector_clock.h"
13
14 namespace blimp {
15
16 namespace proto {
17 class ChangesetMessage;
18 }
19
20 // Syncable is a base class interface that is used for both SyncableObject and
21 // SyncableMember classes.
22 //
23 // Syncable is something that supports creating and restoring Changesets.
24 // Changesets is a state that is propagated between client and server to
Kevin M 2016/10/04 17:28:12 Suggestion: Objects exchange Changesets between th
scf 2016/10/04 21:27:46 Done.
25 // keep corresponding objects eventually synchronized.
26 //
27 // 1. Mapping: There is a one-to-one relationship between instances on the
28 // client and instances on the engine.
29 // 2. Consistency: The values stored in client-engine pairs should eventually be
30 // equal.
31 //
32 // The main difference is that SyncableObject owns its lifetime, whereas
33 // SyncableMember depends on its SyncableObject parent.
34 //
35 // An example for GeoLocation would be:
36 // GeoLocation : SyncableObject {
37 // * Frequency : SyncableMember
38 // * Position : SyncableMember
39 // }
40 //
41 // VectorClocks from a SyncableMember can be compared with the VectorClock from
42 // the SyncableObject. This reduces the amount of state that needs to be kept.
43
44 template <class ChangesetType>
45 class Syncable {
46 public:
47 virtual ~Syncable() {}
48
49 // Constructs a changeset between the |from| revision and its current state.
50 // The Sync layer will encapsulate the changeset with details since |from|,
51 // but the Object is responsible for including any revision information
52 // additional to that expressed by the VectorClocks, that is necessary to
53 // detect and resolve conflicts.
54 // The computed changeset is returned asynchronously as a return parameter.
55 virtual std::unique_ptr<ChangesetType> CreateChangesetToCurrent(
56 const VectorClock& from) = 0;
57
58 // Applies a |changeset| given as parameter to the contents of the
59 // Syncable.
60 // The VectorClocks |from| and |to| can be used to detect and resolve
61 // concurrent change conflicts.
62 virtual void ApplyChangeset(const VectorClock& from,
63 const VectorClock& to,
64 std::unique_ptr<ChangesetType> changeset) = 0;
Kevin M 2016/10/04 17:28:11 This one's going to have to be async. We need to g
scf 2016/10/04 21:27:46 After discussing offline with @kevin and @wez we d
65
66 // Gives a chance for the Syncable to delete any old data previous to the
67 // |checkpoint|. This is a pretty important method that will remove some
68 // memory pressure for example from the UniqueSet CRDTs. They need to keep
69 // a growing list of added/removed elements over time. With this checkpoint
70 // info they can delete those elements prior to the vector clock specified in
71 // |checkpoint|.
72 virtual void ReleaseCheckpointsBefore(const VectorClock& checkpoint) = 0;
73 };
74
75 class SyncableObject : public Syncable<proto::ChangesetMessage> {
76 public:
77 explicit SyncableObject(const VectorClock& clock);
78 ~SyncableObject() override {}
79
80 const VectorClock& clock() const { return clock_; }
81
82 VectorClock* mutable_clock() { return &clock_; }
83
84 protected:
85 // The clock is needed in order for the |SyncableMember| objects whenever
86 // they modify their state they update their |last_modified_| value.
87 // The rationale here is use a "global" per SyncableObject clock which makes
88 // state management a lot simpler.
89 VectorClock clock_;
90
91 private:
92 DISALLOW_COPY_AND_ASSIGN(SyncableObject);
93 };
94
95 template <class ChangesetType>
96 class SyncableMember : public Syncable<ChangesetType> {
97 public:
98 explicit SyncableMember(SyncableObject* parent);
99 ~SyncableMember() override {}
100
101 // Returns true if the object have been modified since |from|.
102 virtual bool ModifiedSince(const VectorClock& from) = 0;
103
104 protected:
105 // Increments the parent clock and returns the new value. Should be used
106 // whenever a SyncableMember updates its state.
107 VectorClock IncrementParentClock();
108
109 // Returns the current value of the vector clock of the parent object (aka
110 // SyncableObject).
111 const VectorClock& parent_clock() const;
112
113 private:
114 SyncableObject* parent_;
115 DISALLOW_COPY_AND_ASSIGN(SyncableMember);
116 };
117
118 SyncableObject::SyncableObject(const VectorClock& clock) : clock_(clock) {}
119
120 template <class ChangesetType>
121 SyncableMember<ChangesetType>::SyncableMember(SyncableObject* parent)
122 : parent_(parent) {}
123
124 template <class ChangesetType>
125 VectorClock SyncableMember<ChangesetType>::IncrementParentClock() {
126 parent_->mutable_clock()->IncrementLocal();
127 return parent_->clock();
128 }
129
130 template <class ChangesetType>
131 const VectorClock& SyncableMember<ChangesetType>::parent_clock() const {
132 return parent_->clock();
133 }
134
135 } // namespace blimp
136
137 #endif // BLIMP_NET_HELIUM_SYNCABLE_H_
OLDNEW

Powered by Google App Engine
This is Rietveld 408576698