This repository has been archived by the owner on Jul 7, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
NOTES
114 lines (75 loc) · 4.04 KB
/
NOTES
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
Interesting cases:
- suppose paragraph P1 is copied to the pasteboard, edited a bit more in the source doc, and then copied again.
=> should we fire a delegate method to imlpement our policy?
- consider when the conflict is on just an inner object of a more complex structure. e.g. copy "group [ circle , square]" , later, copy "group [ diamond, square ]"
seems a good UI might be:
* user does CUT ("pick"): if any conflict occurrs on adding to pasteboard, the entire pasteboard item[s] containing all of the conflicting items are removed.
=> on pasting into an alternate version where the picked object wasn't picked,
we should probably do a copy (relabelling).
* user does COPY ("pick copy"): we just relabel the copy, so there is never a conflict.
- should the root item in a persistent root always have the same UUID as the persistent root?
THOUGHTS jan 2 / 2013
-=-=--=-=-=-=-=-==-=
- concerned about loading custom model object subclasses of COObject. need to re-add metamodel stuff?
=> WIP. Done.
- should build a vector drawing app with group, image, shape so I can test
different object classes (group, image, shape) (and diff/merge!) in a realistic setting.
- attachments / BLOBs?
=> Done.
- for storing the undo log (history of changes to the persistent root data):
the problem of a command-pattern, 2-stack (undo / redo) undo system being too inflexible
should be solved by moving to a 1-stack (action log) system, which looks similar to git's reflog
- Full history import / export needs to be thought about.
- write "document shoebox" app?
- encryption (could be easy with SQLCipher - but it's not bundled with OSes like sqlite), indexing, ...
- add a integer lock version to the COStore methods so we can check within a DB transaction that the version
of the proot metadata on disk is the same as what was in memory.
Undo scheme: Params:
1. set current version for branch [ username='ericw', appname='objectManager' ]
2. set current branch [ username='ericw', appname='objectManager' ]
3. set metadata for branch [ username='ericw', appname='objectManager' ]
4. set metadata for persistent root [ username='ericw', appname='objectManager' ]
5. delete non-current branch [ username='ericw', appname='objectManager' ]
Rules:
Suppose we are in app X and user Y:
(most recent of:
(most recent 1. if app = X and user = Y)
(most recent 2. if app = X and user = Y)
(most recent 3. if app = X and user = Y)
(most recent 4. if app = X and user = Y)
(most recent 5. if app = X and user = Y))
This means we can undo a:
"set current version for branch" before a "set current branch"
"set current version for branch" before a "set metadata for branch"
"set current version for branch" before a "set metadata for persistent root"
"set current branch" before a "set current version for branch"
"set current branch" before a "set metadata for branch"
"set current branch" before a "set metadata for persistent root"
"set metadata for branch" before a "set current version for branch"
"set metadata for branch" before a "set current branch"
"set metadata for branch" before a "set metadata for persistent root"
"set metadata for persistent root" before a "set current version for branch"
"set metadata for persistent root" before a "set metadata for branch"
"set metadata for persistent root" before a "set current branch"
Mar 1
======
Question is, are persistent roots naturally alive, or can we ever GC them due to a lack of references within a store?
=> need to be naturally alive.
1. user creates a document (persistent-root)
workspace proot
|---|
| d-+----. document proot
|---|
2. user deletes the document:
workspace proot
|---|
| | . document proot
| | |
| Tr| |
| |-| |
| |d+----/
-----
this is an undoable change in the workspace. we move the "d" proxy to the Trash (Tr) group inside workspace proot.
We want moving to trash to be undoable in the workspace proot. This will work fine.
After a while we can simply delete the proot.
Workspace app