gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz-commits] manuscripts/storm article.rst


From: Benja Fallenstein
Subject: [Gzz-commits] manuscripts/storm article.rst
Date: Sun, 02 Feb 2003 23:12:20 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/02 23:12:20

Modified files:
        storm          : article.rst 

Log message:
        more 'meat' (explanation of Storm)

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/storm/article.rst.diff?tr1=1.72&tr2=1.73&r1=text&r2=text

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.72 manuscripts/storm/article.rst:1.73
--- manuscripts/storm/article.rst:1.72  Sun Feb  2 22:33:49 2003
+++ manuscripts/storm/article.rst       Sun Feb  2 23:12:19 2003
@@ -555,17 +555,49 @@
                             +---------+
 
 In addition to the pointer and the target, pointer blocks contain
-a list of *obsoleted* pointer blocks. These are pointer blocks
-associated with the same pointer which are 
-
-...
-
+a list of zero or more *obsoleted* pointer blocks. When a new version
+is created, it usually supersedes one older version; when the
+pointer block targeting the new version is created, it obsoletes
+the pointer block targeting the superseded version.
+Only the new, non-obsoleted block will be considered when
+loading the document (although the pointer blocks pointing to
+past versions remain accessible for tracing the document's history).
+
+If, on the other hand, two people collaborate on a document
+and produce two independent versions, neither will obsolete
+the other. When they synchronize their pools by copying
+all new blocks in either to the other, both versions will be
+considered 'current' by the system. The users can then take
+appropriate action, by consolidating the changes in both versions
+(manually or through an automatic merge algorithm),
+or by treating the two versions as alternative. After the
+alternative versions have been consolidated, a pointer block
+obsoleting both consolidated previous versions is created.
+
+XXX talk about security -> we need a way to authenticate authors...
+
+The ability to retain multiple 'current' versions of a document
+can be useful, for example when there is no time to consolidate
+changes at the time of synchronization.
 Yet, it is decidedly inconvenient when every time one opens a document,
 the computer pops up a little window saying, "There are currently
 three different versions of this resource. Which one would you like
 to open?" Overcoming this problem will be an important issue
 as the system matures.
 
+While we see the pointer system as useful for 
+asynchronous collaboration, it is not well suited to Web-like publishing.
+For this, a different system may be practical, where pointer blocks
+store a target and a timestamp; when resolving a pointer, the newest
+pointer block for that pointer would then be selected.
+
+In summary, the current pointer system seems promising, but 
+there are a number of unresolved issues with it:
+
+- signatures needed online
+- multiple 'current' versions annoying
+- not suited to Web-like publishing
+
 
 6.2. Diffs
 ----------
@@ -643,7 +675,11 @@
 in addition to storing the versions above. Then, we can reconstruct
 version ``C`` in two ways: By using the diffs from ``A`` to ``B``
 and ``B`` to ``C``, or, more efficiently, by applying the inverse
-of the diff from ``C`` to ``D`` to version ``D``.
+of the diff from ``C`` to ``D`` to version ``D`` [#]_.
+
+.. [#] Of course, in reality the number of differences
+   that can be 'skipped' will have to be much higher
+   for this mechanism to be useful.
 
 [XXX fig?]
 
@@ -660,7 +696,30 @@
    if incorrect, go back to step 3.
 
 As computing differences is file-format dependent, so is our system
-for storing versions. We 
+for storing versions. In our implementation, applications need to
+provide a callback interface for reading and writing versions
+and computing and applying differences. ::
+
+    +--------------------+      +--------------------+
+    | <<interface>>      |      | <<interface>>      |
+    | Version            |      | Diff               |
+    +====================+      +====================+
+    | getDifferenceFrom  |      | applyTo(:Version): |
+    |   (:Version): Diff |      |   Version          |
+    +--------------------+      |                    |
+                                | inverse(): Diff    |
+                                +--------------------+
+
+        +---------------------------------------+
+        | <<interface>>                                |
+        | VersionFormat                                |
+        +=======================================+
+        | readVersion(:InputStream): Version    |
+        | readDiff(:InputStream): Diff         |
+        |                                       |
+        | writeVersion(:OutputStream, :Version) |
+        | writeDiff(:OutputStream, :Diff)       |
+        +---------------------------------------+
 
 
 7. Peer-to-peer implementations




reply via email to

[Prev in Thread] Current Thread [Next in Thread]