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: Benja Fallenstein
Subject: [Gzz-commits] manuscripts/pointers article.rst
Date: Mon, 10 Nov 2003 06:14:48 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Benja Fallenstein <address@hidden>      03/11/10 06:14:48

Modified files:
        pointers       : article.rst 

Log message:
        make contribution of reverse indexing more clear

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

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.211 
manuscripts/pointers/article.rst:1.212
--- manuscripts/pointers/article.rst:1.211      Mon Nov 10 05:42:37 2003
+++ manuscripts/pointers/article.rst    Mon Nov 10 06:14:47 2003
@@ -202,7 +202,7 @@
 Other approaches to versioning 
 that rely on keeping information about the current version
 in one place on one P2P network will not allow the heterogeneity of different
-systems that is vital for the Web to flourish.
+systems to flourish.
 
 .. [#update] When updating a page, it would be clearly
    infeasible to update all pages linking to it, and thus
@@ -218,11 +218,20 @@
 
 An additional contribution is the Storm data model,
 an API formalizing the notion of searching for data
-by hash and content. The API is used by applications
-such as browsers and implemented for each P2P network
-accessed. Pointer records may be implemented
-on top of the Storm model, rather than separately
+by hash and content. Indexing files by content
+is implemented through application-specific plug-ins.
+Allowing files to be found by any particular property
+of their content (such as the 'album' field in OGG metadata)
+is as easy as writing a simple plug-in.
+Pointer records may be implemented
+on top of the Storm indexing, rather than separately
 for each P2P network.
+The API is used by applications
+such as browsers and implemented for each P2P network
+accessed. 
+
+.. The indices generated by indexing plugins
+   are automatically published on each P2P network.
 
 ..  Like in OceanStore, old
     versions remain fully accessible (as long as somebody
@@ -365,7 +374,7 @@
 to distinguish the pointer from all other documents
 owned by the same entity, for example
 a semantic-free random
-bitstring, 
+bitstring.
 
 To associate pointers with versions, our system uses *pointer records*:
 small files that, similar to OceanStore's heartbeats,
@@ -435,7 +444,10 @@
 
 The Storm abstraction does not provide any new functionality;
 it merely provides a common API for the hash-based addressing
-and content-based search present in many existing P2P systems.
+and content-based search present in many existing P2P systems
+(although allowing files to be found by specific properties
+of their content is much easier to implement using 
+our plugin architecture).
 
 .. [#] For STORage Module. Storm is also the name of our
    Free Software implementation, discussed in
@@ -455,10 +467,10 @@
     for showing a block in a Web browser.)
 
 Reverse indices
-    Reverse indices are application-specific plug-ins
+    Reverse indices are application-specific plugins
     which index blocks by properties of their content
     rather than by hash. Reverse indices examine each
-    block in a local pool and return hashtable keys
+    block in a local data store and return hashtable keys
     under which this block should be found. 
     For example, an index of Ogg Vorbis audio blocks running 
     on an artist's Web server could return each word
@@ -526,11 +538,11 @@
 .. somewhat tangential to this workshop's theme,
    candidate for removal to save space:
 
-In an ad-hoc wireless local network between mobile devices,
-the latest issue of, e.g., Slashdot (an popular online news site)
-could be downloaded from other devices' caches, instead
-of paying for wireless Internet access; trust would not be
-an issue as the pointer records' signatures could be validated.
+   In an ad-hoc wireless local network between mobile devices,
+   the latest issue of, e.g., Slashdot (an popular online news site)
+   could be downloaded from other devices' caches, instead
+   of paying for wireless Internet access; trust would not be
+   an issue as the pointer records' signatures could be validated.
 
 The peer-to-peer network we propose would use
 random-looking, semantic-free identifiers; arguments for this
@@ -596,7 +608,7 @@
 
    -- XXX we don't distribute anything yet
 
-Our prototype provides implementations of the block/pool abstraction
+Our prototype provides implementations of the block abstraction
 and of reverse indexing for both local storage
 and distribution through the GISP DHT [kato02gisp]_.
 The API is sufficiently abstract that different overlays
@@ -670,7 +682,7 @@
 past versions inaccessible. By simply signing and publishing
 a large number of "fake" versions (e.g., files containing
 random data), a publisher could make correct past versions
-hard to access. A time-stamping mechanism may help here.
+hard to access.
 
 In this paper, we have proposed to use pointer records as the versioning
 mechanism for a location-independent Web.




reply via email to

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