gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz-commits] manuscripts/pointers article.rst


From: Tuomas J. Lukka
Subject: [Gzz-commits] manuscripts/pointers article.rst
Date: Mon, 10 Nov 2003 04:11:15 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Tuomas J. Lukka <address@hidden>        03/11/10 04:11:15

Modified files:
        pointers       : article.rst 

Log message:
        Editing data model

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/pointers/article.rst.diff?tr1=1.187&tr2=1.188&r1=text&r2=text

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.187 
manuscripts/pointers/article.rst:1.188
--- manuscripts/pointers/article.rst:1.187      Mon Nov 10 04:04:08 2003
+++ manuscripts/pointers/article.rst    Mon Nov 10 04:11:14 2003
@@ -399,22 +399,11 @@
 peer-to-peer network; this could be a DHT, a flooding broadcasting
 network like Gnutella [gnutellaurl]_, or any other P2P architecture.
 
-In addition to the above information, a pointer record
-may contain a list of versions that the current version
-is based on. If a user edited the document, this would be
-the previous version. If the system merged two versions
-created by different users, this would be the two merged versions.
-The resulting directed acyclic graph can be used to detect
-situations where a document has been concurrently edited
-on two different machines, requiring a merge.
-(This approach was introduced in [fallenstein03storm]_.)
-
 Contrary to other systems, our
 system treats pointer records as *first-class citizens*;
 pointer records
 are treated just as normal data files 
 and may reside on (and be downloaded from) any host.
-
 For example, a filesharing system could, for every versioned 
 file ``f``, store two companion files ``f.version`` 
 and ``f.charter``, containing the charter and pointer record 
@@ -423,6 +412,16 @@
 searching for versions of this document. It could also use it
 to notify the user when new versions of the file become available.
 
+In addition to the above information, a pointer record
+may contain a list of versions that the current version
+is based on. If a user edited the document, this would be
+the previous version. If the system merged two versions
+created by different users, this would be the two merged versions.
+The resulting directed acyclic graph can be used to detect
+situations where a document has been concurrently edited
+on two different machines, requiring a merge.
+(This approach was introduced in [fallenstein03storm]_.)
+
 Because they require no centralized version management,
 pointer records may be able to unify the namespaces
 of different P2P systems in a similar way to hash-based identifiers.
@@ -433,9 +432,9 @@
 in Gnutella or a DHT-based system, using an anonymized system
 like Achord [hazel02achord]_ if it contains controversial content.
 
-XXX something that requires keeping info in one place
-in one network will never be agreeable upon between
-all networks
+..  XXX something that requires keeping info in one place
+    in one network will never be agreeable upon between
+    all networks
 
 ..  - Carries over the four benefits from hash-based addressing:
 
@@ -449,18 +448,18 @@
 The Storm data model
 ====================
 
-XXX say in this section: a way to decouple inventions
-on the application layer, like pointer records, from
-inventions in the underlying P2P distribution-- like e.g. IP
-
-XXX focus on the formalization of blocks and our 
-generalization of reverse indexing
+..  XXX focus on the formalization of blocks and our 
+    generalization of reverse indexing
 
 In this section, we introduce the Storm [#]_ data model, 
 an API providing simple but powerful abstraction over both local storage
-and several types of P2P network. The Storm API can be used
-by P2P Web applications, which then do not have to deal
-with each P2P network implementation independently.
+and several types of P2P network. The intent
+of this API is to decouple the application and network layers
+so that both can evolve independently.
+
+..  The Storm API can be used
+    by P2P Web applications, which then do not have to deal
+    with each P2P network implementation independently.
 
 The Storm abstraction does not provide any new functionality;
 it merely provides a common API for the hash-based addressing




reply via email to

[Prev in Thread] Current Thread [Next in Thread]