[Gzz-commits] manuscripts/pointers article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Benja Fallenstein <address@hidden>      03/11/10 04:49:05

Modified files:
        pointers       : article.rst 

Log message:
        rmcrud that we're extremely unlikely to use after this point

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

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.202 
manuscripts/pointers/article.rst:1.203
--- manuscripts/pointers/article.rst:1.202      Mon Nov 10 04:45:08 2003
+++ manuscripts/pointers/article.rst    Mon Nov 10 04:49:05 2003
@@ -114,9 +114,6 @@
 and increase availability; pages would stay online as long as
 any user keeps a copy of them on their local harddisk.
 
-.. XXX Mention "Name-based not possible as a suitable system
-   for names doesn't exist?"
-
 Such permanence is an important concern, as seen by the following example.
 In 1997, NASA launched the Cassini-Huygens spacecraft
 on a mission to Saturn. Before the launch, the mission
@@ -160,6 +157,7 @@
        a change in the user interface or functionality, 
        and to use a neighbouring computer's cache
        if the LAN is disconnected from the internet 
+
 Heterogeneity
        The possibility to
        use different P2P networks interchangeably, even
@@ -169,6 +167,11 @@
        exploits of single network; b) one size doesn't fit all
        (e.g. anonymity, efficiency); c) more people can use this
        (network effect)
+
+..  XXX something that requires keeping info in one place
+    in one network will never be agreeable upon between
+    all networks
+
 Distributed archivability
        The ability to
        keep a version originally published by 
@@ -177,22 +180,6 @@
        (so that when the original publisher loses interest,
        a page does not fall off the Web).
 
-.. To keep a version 
-   of a page online, it does not suffice for one user
-   to download and store a copy; when the publisher
-   loses interest, the page disappears (except in the case
-   of Freenet, where pages disappear when they have not been
-   requested for a period of time).
-
-
-..  In conclusion, 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. XXX not true
-
-    Thus, in these systems, when the original publisher loses interest
-    and stops publishing a page, it disappears, even if
-    someone else has kept a copy.
-
 In a P2P Web, pages could be
 linked using  permanent URIs 
 based on the files' cryptographic 
@@ -211,25 +198,6 @@
    infeasible to update all pages linking to it, and thus
    all pages linking to *them*, and thus...
 
-..  There are some non-filesharing P2P systems 
-    that do offer an update mechanism. However, none of these
-    provides all the above benefits of a filesharing system: 
-
-
-.. <<<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 filesharing system,
-   and links should continue to work.>>>
-
-.. <<<Other projects exploit some of the advantages of hash-based
-   (storage systems: CFS, PAST; web caching: Squirrel),
-   but don't address the Web.>>>
-
-.. Possibility of desktop integration in ways that the location-dependent
-   Web cannot archieve, through the novel combination of
-   network transparency and location independence (ref ourselves).
-
 The main contribution of this paper is the use of *pointer records*,
 a versioning mechanism which is similar to OceanStore's heartbeats,
 but allows the clients to download and store the pointer records
@@ -238,10 +206,6 @@
 the whole P2P network for pointer records
 related to a document.
 
-..  XXX something that requires keeping info in one place
-    in one network will never be agreeable upon between
-    all networks
-
 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
@@ -364,8 +328,6 @@
    semantics; for example, the NFS client for OceanStore only requests
    new heartbeats less than 30 seconds old.
 
-..  is unique among the versioned P2P systems
-    in that it 
 
 Pointer records
 ===============
@@ -441,21 +403,10 @@
 in Gnutella or a DHT-based system, using an anonymized system
 like Achord [hazel02achord]_ if it contains controversial content.
 
-..  - Carries over the four benefits from hash-based addressing:
-
-      - Version references movable between servers
-      - Past versions accessible as long as anyone keeps a copy
-      - Load balancing (download the pointer record from whoever has it)
-      - Can use one addressing scheme for *updateable* information,
-       searching different networks for versions
-
 
 The Storm data model
 ====================
 
-..  XXX focus on the formalization of blocks and our 
-    generalization of reverse indexing
-
 In this section, we introduce the Storm [#]_ data model, 
 an API for storing and retrieving information using
 hash-based addressing. Storm provides a simple but powerful
@@ -464,10 +415,6 @@
 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
 and content-based search present in many existing P2P systems.
@@ -501,15 +448,6 @@
     The server would publish the resulting mappings
     from words to block ids on the P2P network.
 
-.. XXX kept out because of space constraints:
-
-   An index can also return additional information
-   to be placed in the hashtable along with the
-   block id. In the example, this could be the complete
-   metadata of the song, so that a client does not need
-   to download the complete audio file before being able
-   to show its artist, title etc. to its user.
-
 The pointer functionality is trivial to implement
 *on top of* this basic model. A pointer record
 is simply a block with a special MIME type. A pointer record index
@@ -533,10 +471,6 @@
 its address when published on the network, or when
 downloaded to the local harddisk [fallenstein03storm]_.
 
-.. - can be made to work with peers that join and leave small
-     ad hoc networks often (and the global "net" less often)
-   -> XXX what does this mean?
-
 
 Applications
 ============
@@ -551,8 +485,6 @@
 is the implementation of a file-shared web
 in a distributed, decentralized and above all
 *heterogeneous* way.
-
-.. XXX heterogeneous *how*?
 
 Using pointer records, we can provide the functionality
 of static web pages. While dynamic web pages generated