/[gzz]/manuscripts/storm/article.rst
ViewVC logotype

Diff of /manuscripts/storm/article.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.61 by hemppah, Fri Jan 31 10:58:56 2003 UTC revision 1.62 by hemppah, Fri Jan 31 11:25:07 2003 UTC
# Line 19  unique random identifiers are not global Line 19  unique random identifiers are not global
19  However, recent developments in peer-to-peer systems have  However, recent developments in peer-to-peer systems have
20  rendered this assumption obsolete. Distributed hashtables  rendered this assumption obsolete. Distributed hashtables
21  [ref chord, can, tapestry, pastry, kademlia, symphony, viceroy]  [ref chord, can, tapestry, pastry, kademlia, symphony, viceroy]
22  and similar systems [skip graph, swan] allow routing based on  and similar systems [skip graph, swan] allow *location independent* routing
23  random identifiers on a global scale. This, we believe,  based on random identifiers on a global scale. This, we believe,
24  may be the most important result of peer-to-peer  may be the most important result of intense peer-to-peer
25  research with regard to hypermedia.  research with regard to hypermedia.
26    
27  In today's computing world, documents move quite freely between  In today's computing world, documents move quite freely between
# Line 29  computers, being sent as e-mail attachme Line 29  computers, being sent as e-mail attachme
29  published on the web, moved between desktop and laptop systems,  published on the web, moved between desktop and laptop systems,
30  downloaded for off-line reading or copied between computers in a LAN.  downloaded for off-line reading or copied between computers in a LAN.
31  Often, the same document is independently modified  Often, the same document is independently modified
32  on two unconnected, separete systems. We address two issues  on two more more unconnected, separete systems. We address two issues
33  raised by this *data mobility*: Dangling links, and keeping track  raised by this *data mobility* phenomenon: Dangling links, and keeping track
34  of alternative versions. Resolvable location-independent identifiers  of alternative versions. Resolvable location independent identifiers
35  make these issues much easier to deal with, since data  make these issues much easier to deal with, since data
36  can be recognized whereever it is moved.  can be recognized whereever it is moved.
37    
# Line 46  Storm has been partially implemented as Line 46  Storm has been partially implemented as
46  which uses Storm exclusively for all disk storage. On top of Storm,  which uses Storm exclusively for all disk storage. On top of Storm,
47  we have built a system for storing mutable, versioned data  we have built a system for storing mutable, versioned data
48  and an implementation of Xanalogical storage [ref].  and an implementation of Xanalogical storage [ref].
49    [General figure of Storm, i.e. application layer, storm layer,
50    netowork layer ? -Hermanni]
51    
52  The main contributions of this paper are  The main contributions of this paper are
53    -Storm - which employs new techniques (immutable block storage, *working* links etc.)
54    -use of p2p architecture in hypermedia domain
55    
56  This paper is structured as follows. In next section, we describe  This paper is structured as follows. In next section, we describe
57  related work. In section 3, we introduce the basic storage unit of our  related work. In section 3, we introduce the basic storage unit of our
# Line 60  of mutable data on top of blocks. In sec Line 64  of mutable data on top of blocks. In sec
64  potential peer-to-peer implementations of Storm. In section 8,  potential peer-to-peer implementations of Storm. In section 8,
65  we report on implementation experience and future directions.  we report on implementation experience and future directions.
66  Section 9 concludes the paper.  Section 9 concludes the paper.
67    [Suggestion: In next section, we describe
68    related work. In section 3, we give an overview of Storm. In
69    section 4, we discuss the details of basic storage unit. In
70    section 5, we discuss our implementation of Xanalogical storage
71    on top of the block system. In section 6 we discuss application-specific
72    reverse indexing of blocks by their content and techiques for
73    efficient versioned storage of mutable data on top of blocks. In
74    section 7, we discuss potential peer-to-peer implementations of Storm.
75    In section 8, we report on implementation experience and future
76    directions. Section 9 concludes the paper. -Hermanni]
77    
78    
79  2. Related Work  2. Related Work

Legend:
Removed from v.1.61  
changed lines
  Added in v.1.62

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26