555 |
+---------+ |
+---------+ |
556 |
|
|
557 |
In addition to the pointer and the target, pointer blocks contain |
In addition to the pointer and the target, pointer blocks contain |
558 |
a list of *obsoleted* pointer blocks. These are pointer blocks |
a list of zero or more *obsoleted* pointer blocks. When a new version |
559 |
associated with the same pointer which are |
is created, it usually supersedes one older version; when the |
560 |
|
pointer block targeting the new version is created, it obsoletes |
561 |
... |
the pointer block targeting the superseded version. |
562 |
|
Only the new, non-obsoleted block will be considered when |
563 |
|
loading the document (although the pointer blocks pointing to |
564 |
|
past versions remain accessible for tracing the document's history). |
565 |
|
|
566 |
|
If, on the other hand, two people collaborate on a document |
567 |
|
and produce two independent versions, neither will obsolete |
568 |
|
the other. When they synchronize their pools by copying |
569 |
|
all new blocks in either to the other, both versions will be |
570 |
|
considered 'current' by the system. The users can then take |
571 |
|
appropriate action, by consolidating the changes in both versions |
572 |
|
(manually or through an automatic merge algorithm), |
573 |
|
or by treating the two versions as alternative. After the |
574 |
|
alternative versions have been consolidated, a pointer block |
575 |
|
obsoleting both consolidated previous versions is created. |
576 |
|
|
577 |
|
XXX talk about security -> we need a way to authenticate authors... |
578 |
|
|
579 |
|
The ability to retain multiple 'current' versions of a document |
580 |
|
can be useful, for example when there is no time to consolidate |
581 |
|
changes at the time of synchronization. |
582 |
Yet, it is decidedly inconvenient when every time one opens a document, |
Yet, it is decidedly inconvenient when every time one opens a document, |
583 |
the computer pops up a little window saying, "There are currently |
the computer pops up a little window saying, "There are currently |
584 |
three different versions of this resource. Which one would you like |
three different versions of this resource. Which one would you like |
585 |
to open?" Overcoming this problem will be an important issue |
to open?" Overcoming this problem will be an important issue |
586 |
as the system matures. |
as the system matures. |
587 |
|
|
588 |
|
While we see the pointer system as useful for |
589 |
|
asynchronous collaboration, it is not well suited to Web-like publishing. |
590 |
|
For this, a different system may be practical, where pointer blocks |
591 |
|
store a target and a timestamp; when resolving a pointer, the newest |
592 |
|
pointer block for that pointer would then be selected. |
593 |
|
|
594 |
|
In summary, the current pointer system seems promising, but |
595 |
|
there are a number of unresolved issues with it: |
596 |
|
|
597 |
|
- signatures needed online |
598 |
|
- multiple 'current' versions annoying |
599 |
|
- not suited to Web-like publishing |
600 |
|
|
601 |
|
|
602 |
6.2. Diffs |
6.2. Diffs |
603 |
---------- |
---------- |
675 |
in addition to storing the versions above. Then, we can reconstruct |
in addition to storing the versions above. Then, we can reconstruct |
676 |
version ``C`` in two ways: By using the diffs from ``A`` to ``B`` |
version ``C`` in two ways: By using the diffs from ``A`` to ``B`` |
677 |
and ``B`` to ``C``, or, more efficiently, by applying the inverse |
and ``B`` to ``C``, or, more efficiently, by applying the inverse |
678 |
of the diff from ``C`` to ``D`` to version ``D``. |
of the diff from ``C`` to ``D`` to version ``D`` [#]_. |
679 |
|
|
680 |
|
.. [#] Of course, in reality the number of differences |
681 |
|
that can be 'skipped' will have to be much higher |
682 |
|
for this mechanism to be useful. |
683 |
|
|
684 |
[XXX fig?] |
[XXX fig?] |
685 |
|
|
696 |
if incorrect, go back to step 3. |
if incorrect, go back to step 3. |
697 |
|
|
698 |
As computing differences is file-format dependent, so is our system |
As computing differences is file-format dependent, so is our system |
699 |
for storing versions. We |
for storing versions. In our implementation, applications need to |
700 |
|
provide a callback interface for reading and writing versions |
701 |
|
and computing and applying differences. :: |
702 |
|
|
703 |
|
+--------------------+ +--------------------+ |
704 |
|
| <<interface>> | | <<interface>> | |
705 |
|
| Version | | Diff | |
706 |
|
+====================+ +====================+ |
707 |
|
| getDifferenceFrom | | applyTo(:Version): | |
708 |
|
| (:Version): Diff | | Version | |
709 |
|
+--------------------+ | | |
710 |
|
| inverse(): Diff | |
711 |
|
+--------------------+ |
712 |
|
|
713 |
|
+---------------------------------------+ |
714 |
|
| <<interface>> | |
715 |
|
| VersionFormat | |
716 |
|
+=======================================+ |
717 |
|
| readVersion(:InputStream): Version | |
718 |
|
| readDiff(:InputStream): Diff | |
719 |
|
| | |
720 |
|
| writeVersion(:OutputStream, :Version) | |
721 |
|
| writeDiff(:OutputStream, :Diff) | |
722 |
|
+---------------------------------------+ |
723 |
|
|
724 |
|
|
725 |
7. Peer-to-peer implementations |
7. Peer-to-peer implementations |