[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: |
Fri, 31 Jan 2003 01:57:16 -0500 |
CVSROOT: /cvsroot/gzz
Module name: manuscripts
Changes by: Benja Fallenstein <address@hidden> 03/01/31 01:57:16
Modified files:
storm : article.rst
Log message:
twid
CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/storm/article.rst.diff?tr1=1.59&tr2=1.60&r1=text&r2=text
Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.59 manuscripts/storm/article.rst:1.60
--- manuscripts/storm/article.rst:1.59 Thu Jan 30 10:24:25 2003
+++ manuscripts/storm/article.rst Fri Jan 31 01:57:16 2003
@@ -1,54 +1,60 @@
-========================================================================
-Don't fence me in: Supporting data mobility through the Gzz/Storm design
-========================================================================
+============================================================================
+Gzz Storm: Supporting data mobility through location independent identifiers
+============================================================================
(an-other way (too buzzwordy? but generalized!): enabling distributed
mobile hypermedia with location independent unique document identifiers)
+['distributed mobile hypermedia' is too limited --b.]
1. Introduction
===============
-An important assumption underlying the Web and many other hypermedia
-systems is that an identifier, if it is to be resolvable, must
-include information about where to find the resource it identifies.
-On the Web, for instance, documents are tightly bound to one location: they
-cannot be moved to a different server without breaking links to them[#]_.
-It is the norm for hypermedia systems to bind documents to hosts, much
-like the Web.
-
-Berners-Lee [ref NameMyth] argues that identifying documents
-by unique, completely random identifiers may be desirable,
-as unlike for a URL, there is little reason for a random identifier
-ever to be changed, but that it is not possible to resolve such names
-on a global scale.
+The Web and many other hypermedia systems assume that identifiers
+either have to include location information (as in URLs, which break
+when documents are moved), or can only be resolved locally (as in
+link services that can only find links stored on a select set
+of link servers [ref Microcosm, DLS, ...]). Berners-Lee [ref NameMyth] argues
that
+unique random identifiers are not globally feasible for this reason.
+
+However, recent developments in peer-to-peer systems have
+rendered this assumption obsolete. Distributed hashtables
+[ref chord, can, tapestry, pastry, kademlia, symphony, viceroy]
+and similar systems [skip graph, swan] allow routing based on
+random identifiers on a global scale. This, we believe,
+may be the most important result of peer-to-peer
+research with regard to hypermedia.
-However, in today's computing world, documents move quite freely between
+In today's computing world, documents move quite freely between
computers, being sent as e-mail attachments, carried around on disks,
published on the web, moved between desktop and laptop systems,
downloaded for off-line reading or copied between computers in a LAN.
Often, the same document will be independently modified
-on two unconnected systems.
-
-Recent development in peer-to-peer systems has made scalable
-*location-independent* indexing systems possible, rendering direct
-identifier-to-location assumption obsolete (emphasize 'location-independent
routing'!)
-[refs: chord, can, tapestry, pastry, kademlia, symphony, viceroy, skip graph,
swan].
-This, we believe, is the most important result of peer-to-peer
-research with regard to hypermedia.
-
-In this paper, we present Storm, a design for dealing with
-dangling links and keeping track of alternative versions,
-taking advantage of these new developments.
-
-The main contributions of this paper are...
+on two unconnected systems. In this paper, we address two issues
+raised by this *data mobility*: Dangling links, and keeping track
+of alternative versions. Resolvable location-independent identifiers
+make these issues much easier to deal with, since data
+can be recognized whereever it is moved.
+
+In this paper, we present Storm (for *storage module*), a design
+for dealing with these issues. Storm provides an interface to
+applications for storing and retrieving data in immutable
+byte sequences identified by cryptographic content hashes
+[ref ht'02 paper], unifying the namespaces of
+private data and documents published on the Internet by
+using the same identifiers for both.
+Storm has been partially implemented as a part of the Gzz project [ref],
+which uses it exclusively for all disk storage. On top of Storm,
+we have built a system for storing mutable, versioned data
+and an implementation of Xanalogical storage [ref].
+The main contributions of this paper are
This paper is structured as follows. In next section, we describe
related work. In section 3, we introduce the basic storage unit of our
system, file-like blocks of data identified by cryptographic hashes.
In section 4, we discuss our implementation of Xanalogical storage
on top of the block system. In section 5, we discuss application-specific
-reverse indexing of blocks by their content, essential for most applications.
+reverse indexing of blocks by their content, essential for many applications.
In section 6, we present techiques for efficient versioned storage
of mutable data on top of blocks. In section 7, we discuss
potential peer-to-peer implementations of Storm. In section 8,
@@ -213,7 +219,7 @@
as regular files, but they are immutable, since any change to the
byte sequence would change the hash (and thus create a different block).
Mutable data structures are built on top of the immutable blocks
-(see Section 5).
+(see Section 6).
hemppah: Or should these lines be inserted to some other section and tell more
about these
systems, e.g. 5.2 ?
@@ -267,7 +273,7 @@
However, we have not put a network implementation into regular use
yet and thus can only describe our design, not report on
implementation experience.
-We discuss peer-to-peer implementations in Section 6, below.
+We discuss peer-to-peer implementations in Section 7, below.
The immutability of blocks should make caching trivial, since it is
never necessary to check for new versions of blocks.
@@ -296,13 +302,13 @@
are completely independent of location; when data is moved
between servers, references to it do not break. (Of course, this
requires that the blocks can be found no matter what server
-they are on. Again, see Section 6.)
+they are on. Again, see Section 7.)
4. Xanalogical storage
======================
-XXX
+Xanalogical storage, pioneered by Project Xanadu [ref],
5. Indexing
@@ -337,8 +343,10 @@
-------------
In Storm, *pointers* are used to implement mutable resources.
-A pointer is an abstract reference that can point to different
-blocks over time.
+A pointer is a globally unique identifier that can refer to
+different blocks over time.
+
+To assign targets to pointers, a special type of block
...
- [Gzz-commits] manuscripts/storm article.rst, (continued)
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/01/28
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/01/29
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/01/29
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/01/29
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/01/29
- [Gzz-commits] manuscripts/storm article.rst, Toni Alatalo, 2003/01/29
- [Gzz-commits] manuscripts/storm article.rst, Toni Alatalo, 2003/01/29
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/01/29
- [Gzz-commits] manuscripts/storm article.rst, Toni Alatalo, 2003/01/29
- [Gzz-commits] manuscripts/storm article.rst, Toni Alatalo, 2003/01/30
- [Gzz-commits] manuscripts/storm article.rst,
Benja Fallenstein <=
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/01/31
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/01/31
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/01/31
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/01/31
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/01/31
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/01/31
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/01/31