gzz-commits
[Top][All Lists]
Advanced

[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: Sat, 15 Feb 2003 10:35:04 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/15 10:35:04

Modified files:
        storm          : article.rst 

Log message:
        more refactoring

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.165 manuscripts/storm/article.rst:1.166
--- manuscripts/storm/article.rst:1.165 Sat Feb 15 10:23:42 2003
+++ manuscripts/storm/article.rst       Sat Feb 15 10:35:04 2003
@@ -752,23 +752,17 @@
 
 In a networked implementation, each peer is responsible
 for indexing the blocks it stores. Since no peer can
-feasibly know all applications that may want indexing,
+feasibly know all applications that may need indexing,
 there may be blocks available on the network that have
 not been indexed by a particular application.
-We do not see this as a problem-- it's just like a block
-being available only if there's a peer which wants it to be--
+We do not see this as a problem --- it's just like a block
+being available only if there's a peer which wants it to be ---
 but applications must be prepared to deal with it.
 
 Locally, on the other hand, it is guaranteed that
 all blocks in a pool are indexed by all applications
-known by the pool, even if the block was added 
-to the pool in a previous session in which the pool
-did not know about the indexing application. To ensure this,
-we maintain for each application a table of blocks
-that have already been indexed. When the Storm pool
-implementation is initialized, it compares the list
-of indexed blocks with the list of all available blocks,
-and asks the application for unindexed blocks' items.
+known by the pool. To ensure this, we check that all blocks
+are indexed when a pool is loaded, and add missing items to the index.
 
 One indexing application that may seem obvious is keyword-based
 full-text search. However, no research has been done
@@ -788,10 +782,9 @@
 6. Versioning
 =============
 
-Clearly, for block storage to be useful, there has to be a way to
-efficiently update documents/maintain different versions of documents. 
-We achieve this by a combination of two mechanisms. Firstly, a 
-*pointer* is an updatable reference to a block.
+We implement mutable documents on top of block storage
+using a combination of two mechanisms.
+Firstly, a *pointer* is an updatable reference to a block.
 Secondly, similar to version control systems like CVS,
 we do not store each version, but only the differences between versions.
 




reply via email to

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