[Gzz-commits] manuscripts/pointers article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Benja Fallenstein <address@hidden>      03/11/03 12:20:18

Modified files:
        pointers       : article.rst 

Log message:
        s/file-sharing/filesharing

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

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.95 
manuscripts/pointers/article.rst:1.96
--- manuscripts/pointers/article.rst:1.95       Mon Nov  3 12:09:23 2003
+++ manuscripts/pointers/article.rst    Mon Nov  3 12:20:17 2003
@@ -6,18 +6,18 @@
 Abstract
 ========
 
-File-sharing systems save bandwidth and increase availability
+Filesharing systems save bandwidth and increase availability
 because there is no single point of failure for a file.
 This would be desirable on the Web.
 However, most current P2P systems have no facility 
 for updating documents, and those that do 
 require keeping the current version as state in the network.
-This loses a major benefit of file-sharing:
+This loses a major benefit of filesharing:
 To keep a version of a Web page available, 
 it should suffice to keep a copy of it on your computer.
 
 In this paper, we present a simple versioning mechanism usable
-for a P2P Web as well as for file-sharing,
+for a P2P Web as well as for filesharing,
 and P2P-based software distribution and upgrading,
 and serve as a common versioning model integrating
 separate P2P networks.
@@ -47,18 +47,18 @@
 .. Introduce location-independent Web idea (citing
    benefits from hash-based addressing)---
 
-If the Web worked like a file-sharing system, there would be
+If the Web worked like a filesharing system, there would be
 no central point of failure for a Web page; it could be downloaded
 from any host that has a copy. This would save bandwidth
 and increase availability. However, if the Web worked like
-a file-sharing system, Web pages could never be updated.
+a filesharing system, Web pages could never be updated.
 
-Some file-sharing systems offer URIs for files (e.g., [XXXref]).
+Some filesharing systems offer URIs for files (e.g., [XXXref]).
 These URIs are based on the files' cryptographic hashes.
 A new version of a Web page would have a different hash,
 and thus a different URI.
 
-There are a few (non-file-sharing) P2P systems 
+There are a few (non-filesharing) P2P systems 
 that do offer an update mechanism. *CFS* [dabek01widearea]_
 is a file system based on Chord [stoica01chord]_, storing
 data in a distributed hashtable (DHT). CFS identifies
@@ -109,13 +109,13 @@
 of a document, such as in the *Content-Addressable Web* 
 proposal [content-addressable-web]_, in which clients download 
 a file's hash through HTTP (using an HTTP URI),
-then download the file through, e.g., a file-sharing network.
+then download the file through, e.g., a filesharing network.
 This provides some of the efficiency advantages of a P2P Web.
 However, there is still a single point of failure, and
 links still break when pages move to a different directory
 or Web server.
 
-In a file-sharing system, a file remains accessible
+In a filesharing system, a file remains accessible
 as long as there is a copy on any of the participating hosts.
 None of the above versioning systems have this property.
 In CFS, version information is stored in the DHT, and only
@@ -158,7 +158,7 @@
 .. <<<We don't propose that every byte of information ever published
    on the Web has to be kept around forever. However,
    we do believe that as long as someone does keep a copy,
-   data should remain accessible, like in a file-sharing system,
+   data should remain accessible, like in a filesharing system,
    and links should continue to work.>>>
 
 .. <<<Other projects exploit some of the advantages of hash-based
@@ -279,10 +279,10 @@
 are treated just as normal data files 
 and may reside on (and be downloaded from) any host.
 
-For example, a file-sharing system could, for every versioned 
+For example, a filesharing system could, for every versioned 
 file ``f``, store two companion file ``f.version`` 
 and ``f.charter``, containing the charter and pointer record 
-associated with this version of this file. The file-sharing 
+associated with this version of this file. The filesharing 
 application could then serve this information to other peers
 searching for versions of this document. It could also use it
 to notify the user when new versions of the file become available.