[Top][All Lists]
[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
- Re: [Gzz-commits] manuscripts/storm article.rst, (continued)
[Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/01
[Gzz-commits] manuscripts/storm article.rst, Toni Alatalo, 2003/02/01
[Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/01
[Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/02
[Gzz-commits] manuscripts/storm article.rst,
Benja Fallenstein <=
[Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/02/03
[Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/02/03
[Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/02/03
[Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/02/03
[Gzz-commits] manuscripts/storm article.rst, Toni Alatalo, 2003/02/03
[Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/03
[Gzz-commits] manuscripts/storm article.rst, Toni Alatalo, 2003/02/04
[Gzz-commits] manuscripts/storm article.rst, Toni Alatalo, 2003/02/04
[Gzz-commits] manuscripts/storm article.rst, Toni Alatalo, 2003/02/04
[Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/02/04