9 |
Motivations and potential solutions are reviewed, and a design for |
Motivations and potential solutions are reviewed, and a design for |
10 |
a system being developed for (these purposes) is presented. |
a system being developed for (these purposes) is presented. |
11 |
The design and a partial implementation of it is evaluated |
The design and a partial implementation of it is evaluated |
12 |
in light of use cases from a realistic(?) scenarios. Open issues are |
in light of use cases from realistic(?) scenarios. Open issues are |
13 |
discussed, and the areas for future work in such as |
discussed, and the areas for future work in such as |
14 |
interoperability, scalability and security is identified. |
interoperability, scalability and security is identified. |
15 |
|
|
96 |
synchronizing irregularly with a central server (as in CVS [ref]), |
synchronizing irregularly with a central server (as in CVS [ref]), |
97 |
a network (as in Lotus Notes [ref]) or directly with each other |
a network (as in Lotus Notes [ref]) or directly with each other |
98 |
(as in Groove[?] [ref]). In each of these cases, a user should be able |
(as in Groove[?] [ref]). In each of these cases, a user should be able |
99 |
|
to work on the version at hand and then either merge it with others |
100 |
|
or fork to a different branch. |
101 |
|
|
102 |
In this paper, we present Storm (for *storage module*), a design |
In this paper, we present Storm (for *storage module*), a design |
103 |
dealing with these issues. Storm is a library |
dealing with these issues. Storm is a library |