201 |
has been moved, and redirect it accordingly [rfc2068]_. However, |
has been moved, and redirect it accordingly [rfc2068]_. However, |
202 |
this is not required, and there are no facilities for |
this is not required, and there are no facilities for |
203 |
updating a link automatically when its target is moved. |
updating a link automatically when its target is moved. |
204 |
The HTTP protocol does include a "LINK" request |
The HTTP protocol includes a "LINK" request |
205 |
for creating a relationship between a set of URIs, |
for creating a relationship between a set of URIs, |
206 |
but this feature has never been commonly implemented [reich-davis99-ohp]_. |
but this feature has never been commonly implemented [reich-davis99-ohp]_. |
207 |
|
|
575 |
the basic assertion holds. |
the basic assertion holds. |
576 |
|
|
577 |
Even when a publisher's server fails to serve a block, |
Even when a publisher's server fails to serve a block, |
578 |
links to it will not cease to work until *no* other peer |
links to it will work until *no* other peer |
579 |
holds a copy. This means that providing mirrors is trivial. |
holds a copy. Thus, providing mirrors is trivial. |
580 |
Even after failure of all of the publisher's mirrors, |
Even after failure of all of the publisher's mirrors, |
581 |
a document may still be available from peers that have |
a document may still be available from peers that have |
582 |
downloaded it. An archive of published blocks, in the spirit |
downloaded it. An archive of published blocks, in the spirit |
583 |
of the Web archive [waybackmachine]_, would only be yet another backup; |
of the Web archive [waybackmachine]_, would only be yet another backup: |
584 |
normal links to a block would work as long as the archive |
normal links to a block would work as long as the archive |
585 |
holds a copy. It would also be hard to purposefully remove |
holds a copy. It would also be hard to purposefully remove |
586 |
a published document from the network; whether this is |
a published document from the network; whether this is |
587 |
a good or a bad property we leave for the reader to judge. |
a good or a bad property we leave for the reader to judge. |
588 |
|
|
589 |
Finally, because blocks are easy to move from system |
Finally, because blocks are easy to move from system |
590 |
to system, we hope that block storage may be more *durable* than files. |
to system, we hope that block storage will be more *durable* than files. |
591 |
When users own multiple systems, or buy new systems |
When users own multiple systems, or buy new systems |
592 |
to replace old ones, files are often on one harddisk |
to replace old ones, files are often on one harddisk |
593 |
and not the other, or moved to an old floppy disk but not back |
and not the other, or moved to a floppy disk but not back |
594 |
to the harddisk. How many files you created in the 80s |
to the harddisk. How many files you created in the 80s |
595 |
do you still keep around on your harddisk today? With block storage, |
do you still keep around on your harddisk today? With block storage, |
596 |
each time you buy a new computer, it would be possible |
each time a user buys a new computer, they could |
597 |
to transfer all blocks from your existing systems to the new one, |
transfer all blocks from their existing systems to the new one, |
598 |
and if you left some lying around on a floppy, you would be able |
and blocks from old floppies could be copied to the harddisk |
599 |
to copy it to your harddisk without thinking about issues |
without thinking about issues like which directory |
600 |
like which directory to keep it in. By making it easy to collect |
to keep them in. By making it easy to collect |
601 |
blocks produced on a diverse number of systems, it would be easier |
blocks produced on a diverse number of systems, it would be easier |
602 |
to actually keep that old data around. |
to keep old data around. |
603 |
|
|
604 |
Of course, to meet this goal it is necessary that the block |
Of course, to meet this goal it is necessary that the block |
605 |
system remains backwards compatible at all times. We have therefore |
system remains backwards compatible at all times. We have therefore |
660 |
table of known peers, and issues with UDP and network |
table of known peers, and issues with UDP and network |
661 |
address translation [rfc3253]_). |
address translation [rfc3253]_). |
662 |
|
|
663 |
Sometimes it is useful to think about *zones* blocks are in, |
To implement *Xanalogical storage* in Storm, in each editor session we |
|
related to distribution policy: for example, a *public* |
|
|
zone for blocks served to others in the network, a *private* |
|
|
zone for a user's own data, and a *local* zone with blocks |
|
|
served to anyone on the local intranet. It is essential |
|
|
that blocks from a private zone are not leaked into a public |
|
|
zone without the user's consent. On the other hand, making |
|
|
a document available on the network should be as easy as |
|
|
hitting a 'publish' button moving it to a public zone, |
|
|
possibly also uploading it to a server permanently connected |
|
|
to the Internet, if one is available. |
|
|
|
|
|
We have unfortunately not found a satisfactory representation |
|
|
of zones yet. In particular, how do we decide which zone |
|
|
a new block should be in? Probably in the private zone |
|
|
in many cases, but if we have been editing a document |
|
|
collaboratively edited in a workgroup, we would want |
|
|
our changes to be available to the same group. |
|
|
|
|
|
An important open issue with block storage are |
|
|
UI conventions for listing, moving and deleting blocks. |
|
|
Currently, the only interface is a file system directory |
|
|
containing a set of blocks as files with hexadecimal, |
|
|
random-looking names. In Gzz, we currently trick our way around |
|
|
the problem; at startup time, we simply load the most current |
|
|
version of a document whose identifier is hard-wired into |
|
|
the software (mutable documents are described in section 6.1). |
|
|
|
|
|
4.2. Xanalogical storage on top of blocks |
|
|
----------------------------------------- |
|
|
|
|
|
In Storm, in each editor session we |
|
664 |
create a block with all characters entered in this session (the content type |
create a block with all characters entered in this session (the content type |
665 |
being ``text/plain``). To designate a span of characters |
being ``text/plain``). To designate a span of characters |
666 |
from that session, we use the block's id, the offset of the first |
from that session, we use the block's id, the offset of the first |
669 |
|
|
670 |
In Xanadu, characters are stored to append-only *scrolls* |
In Xanadu, characters are stored to append-only *scrolls* |
671 |
when they are typed [ref?]. Because of this, in Storm, we call the |
when they are typed [ref?]. Because of this, in Storm, we call the |
672 |
blocks containing the actual characters *scroll blocks*. The documents |
blocks containing the actual characters *scroll blocks*. Documents |
673 |
do not actually contain the characters; instead, they are |
do not actually contain characters; instead, they are |
674 |
*virtual files* containing span references as described above. |
*virtual files* containing references to spans. |
675 |
To show a document, the scroll blocks it references are loaded |
To show a document, the scroll blocks it references are loaded |
676 |
and the characters retrieved from there [#]_. |
and the characters retrieved from there [#]_. |
677 |
|
|
684 |
stored once, in a block only referred to wherever |
stored once, in a block only referred to wherever |
685 |
the data is transcluded. |
the data is transcluded. |
686 |
|
|
687 |
|
An important open issue with block storage are |
688 |
|
UI conventions for listing, moving and deleting blocks. |
689 |
|
|
690 |
|
.. Currently, the only interface is a file system directory |
691 |
|
containing a set of blocks as files with hexadecimal, |
692 |
|
random-looking names. In Gzz, we currently trick our way around |
693 |
|
the problem; at startup time, we simply load the most current |
694 |
|
version of a document whose identifier is hard-wired into |
695 |
|
the software (mutable documents are described in section 6.1). |
696 |
|
|
697 |
|
|
698 |
5. Application-specific reverse indexing |
5. Application-specific reverse indexing |
699 |
======================================== |
======================================== |
860 |
for off-line as well as on-line work. |
for off-line as well as on-line work. |
861 |
For long-term publishing, one-time signatures have been |
For long-term publishing, one-time signatures have been |
862 |
found useful [anderson98erl]_. For the time being, the pointer mechanism |
found useful [anderson98erl]_. For the time being, the pointer mechanism |
863 |
works only in trusted Storm zones (Section 4), e.g. |
works only in trusted Storm pools (Section 4), e.g. |
864 |
in a workgroup collaborating on a set of documents. |
in a workgroup collaborating on a set of documents. |
865 |
|
|
866 |
.. [#] Without timestamps, digital signatures are only valid |
.. [#] Without timestamps, digital signatures are only valid |
1096 |
B sets the document public (how that is done depends on UI |
B sets the document public (how that is done depends on UI |
1097 |
implementation), i.e. putting in a published pool, which may reside |
implementation), i.e. putting in a published pool, which may reside |
1098 |
locally or externally e.g. on a (dedicated) server that is "always-on". |
locally or externally e.g. on a (dedicated) server that is "always-on". |
1099 |
These public/private zones are an area where future research is needed, |
These public/private pools are an area where future research is needed, |
1100 |
possibly related to rights and permissions etc. too. |
possibly related to rights and permissions etc. too. |
1101 |
|
|
1102 |
Comments may be new entities(?) linking to it |
Comments may be new entities(?) linking to it |