1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
Journal design:
===============
Eben:
Instead, we were trying to capture "sessions"
as actions which reference one or more objects, where a session, or an
action, is basically one continuous use of a given activity. In the
case of record, this might create several photos (separate objects),
which get grouped into the action. Most activities would have a 1-1
association with objects, but not all.
This also gives us a way to describe actions other than "working in an
activity." For instance, we might have an action for "copy _object_ to
_flash_", "sent _object_ to_person_", or "received _object_ from
_person_". Also, things like "became friends with _person_" and
"joined _group_" would be great to have. We could have "installed
_activity_" and "updated _activity_" actions. Etc.
As seen here (http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#01),
we might also distinguish between viewing and modifying objects. If I
read a document without making edits to it, we could say as much, and
that action would reference the same version of the same object as
another action.
I think the standard procedure for creating an action is the usual
process of starting or resuming an activity, working with that
activity for some duration, and then stopping the activity again. This
series of steps will normally result in a single action. (Pressing
"keep" manually would introduce additional ones.) Most likely, the
Journal/DS would create an action and provide that to the activity to
add to as needed. Record, for instance, would periodically add new
image objects to that action. If it so desired, an activity could also
request a new action from the Journal.
Yes, in a sense, the idea was to expose versioning directly in the
actions view, where you can follow your history of actions
chronologically. Looking back in time would show earlier actions,
referencing earlier versions of objects. The object view, on the other
hand, would provide a "collapsed" view with each object "history"
represented only once. Going into the details view for any object
would allow one to see other versions.
We could also explore expand/collapse controls in object view for
revealing versions...
Yup. I think we can make the search and tagging even more powerful by
supporting user created metadata as well. This is obviously an
advanced feature, but that's OK with me since it doesn't get in the
way of basic use. Typing in key:value pairs into the tag field should
provide searchable keys. In this manner, it should be possible to do
searches for "color:red" to match only on entries which have the value
"red" for the key "color", instead of all entries which had the tag
"red", or the word "red" in their titles, etc.
> The problem is - user can use any symbols in tag name(including spaces)
> at the same time Library needs datastore to make exact query by this
> tag and do not mess tag name with words in description field for
> example.
This was a conscious decision, actually. We didn't want to confuse
kids by imposing a required structure on tags. So, all tags are space
delimited, though my hope was that we could "silently" support quoted
tags if they were typed as such.
In any case, I'm not sure that the fact that the tag string "white
house" being, technically, two tags actually breaks things. These
kinds of overlaps will be few, and a search for the two independent
tags "white" and "house" would still being up the entry in question.
That sounds pretty broken, insofar as the activity_id, from the
perspective of the design team anyway, was meant to be the constant
which remained across versions/sessions specifically for the purpose
of retaining that collaboration thread. I believe there was some talk
of renaming it the collaboration_id at one point, but there were
already too many terms and too much confusion, so we left it as is.
It might be worth asking Sascha where her work on proper versioning is
going, since it's really the (activity_id, version_id) tuple that
should uniquely identify a specific object, I think.
I know GroupThink does everything it can to prevent collisions, but
with this we should also be thinking about the worst case. The
intended baseline behavior (before we get into any fancy merging
libraries) was to allow two instances with the same activity_id but
different version_ids to run simultaneously, and be joined by any of
their participants, thus allowing manual copy/paste merging. The
instance left open last would then become, naturally, the most recent
and therefore the "agreed upon" version moving forward.
Tomeu:
About the Actions view, we have a baseline for activities that is
"Worked on Paint for 15 minutes". But activities would be free to
change that to whatever makes most sense.
IDs:
====
Summary:
Might want to have both versioned and unversioned (but version-specific) metadata.
Version IDs should be random IDs.
Branch information might be useful.
Ben:
The datastore is a collection of objects, which are arranged into version
trees. Each object has a tree_id, which is an arbitrary unique identifier
(string) for the version tree. The datastore will generate a new tree_id
each time a new tree is created. Each object also has a version_id, which
indicates the object's place in the tree. The version_id could take the
form of a dotted decimal string like "4.5.2.1".
Some objects are Actions, and some objects are Documents. Each Action
must retain a list to all Documents associated with that Action, each
represented as a (tree_id, version_id) pair. Each Document must retain a
reference to the Action with which it is associated, represented as a
(tree_id, version_id) pair. Each Document is only associated with a
single Action; a new Action that uses a Document must always make a new
version.
Eben:
Anyway, the subtler point here, just for the sake of stating it
outright, is that sending an object to someone and sharing that
activity with them are (as they should be) quite different actions. In
the former case, they just get the object, and can use it as the
starting point for their own modifications, with their own history. In
the latter case, they will wind up with an object with the same
tree_id (and even version_id, for that matter) as the person who
shared it.
> Ok. Maybe we need some new vocabulary like "read/write metadata" vs.
> "read-only metadata". Action<->Document references would have to live in
> "read-only" metadata, managed by the Datastore.
That seems like a reasonable split, but I'm not sure it falls on the
same line as versioned/un-versioned.
The document references make sense in read-only/un-versioned, but I
feel like tags and titles make sense in read-write/un-versioned. Only
activity "state" makes sense to me in read-write/versioned.
Having said all that, it now seems clear to me that what I'm actually
concerned with is doing merges when v_x and v_y are the "most recent"
versions belonging to the individual who resumes them. No matter how
many new versions kids A and B make, a merge should be attempted
between their newest versions, but only their newest versions. So, in
the end, what matters is not (as I foolishly thought when I began to
write this scenario) that we only want to merge when the version
numbers are the same. Silly me.
Unique version numbers are good.
> Heh. We don't support inter-object dependencies. It's amazing how we
> keep having the same discussion over and over, though:
We do. We continually avoid it because it's hard, and because it's
basically orthogonal to the both versions and to "actions". Actions
(which exist only within the Journal) reference other objects, but the
inter-object linking you bring up is not required in this scheme.
Importing an image into eg. Write can (and currently does) still just
embed that image in the resulting write document, instead of
referencing it.
This is for similar reasons to the way activity bundles work. Objects
are self-contained...for better or worse.
Chris Marshall:
One of the concepts from git that I really like is the
concept of the cryptographic data object IDs. It allows
one to easily locate and compare objects and other git
constructs.
A similar type of globally, unique identifier could
allow migration, reference, and reconstitution of journal
objects or activities. That might alleviate one problem
of broken links/dependencies in that you would definitely
know what should be there [at the other end of the link].
Maybe a type of Journal entry like "Bobby's Photo" with the
link and a "Get the Photo" action or starting/resuming an
Activity with it would get the needed object.
|
