[Gzz-commits] gzz/Documentation/misc/benja-diff-fa thesis.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Benja Fallenstein <address@hidden>      03/02/09 21:30:51

Modified files:
        Documentation/misc/benja-diff-fa: thesis.rst 

Log message:
        refs

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/benja-diff-fa/thesis.rst.diff?tr1=1.5&tr2=1.6&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/benja-diff-fa/thesis.rst
diff -u gzz/Documentation/misc/benja-diff-fa/thesis.rst:1.5 
gzz/Documentation/misc/benja-diff-fa/thesis.rst:1.6
--- gzz/Documentation/misc/benja-diff-fa/thesis.rst:1.5 Sun Feb  9 17:34:23 2003
+++ gzz/Documentation/misc/benja-diff-fa/thesis.rst     Sun Feb  9 21:30:51 2003
@@ -34,14 +34,14 @@
 either have to include location information (as in URLs, which break 
 when documents are moved), or can only be resolved locally (as in
 link services that can only find links stored on a select set
-of link servers [ref Microcosm, DLS, ...]). Berners-Lee [name-myth]_
+of link servers [hill94extending-andalso-carr95dls]_). Berners-Lee [name-myth]_
 argues that unique random identifiers are not globally feasible 
 for this reason.
 
 However, recent developments in peer-to-peer systems have
 rendered this assumption obsolete. Structured overlay networks
-[ref chord, can, tapestry, pastry, kademlia, symphony, viceroy,
-skip graph, swan] allow location-independent identifiers
+[stoica01chord-andalso-ratnasamy01can-andalso-zhao01tapestry-andalso-rowston01pastry-andalso-maymounkov02kademlia-andalso-malkhi02viceroy-andalso-AspnesS2003-andalso-bonsma02swan]_
+allow location-independent identifiers
 to be resolved on a global scale. 
 It is now feasible to do a global search to find all information
 about a given identifier, on any peer in the network.
@@ -87,7 +87,8 @@
 to documents stored on either one's computer [thompson01coincidence]_.
 
 Advanced hypermedia systems such as Microcosm and Hyper-G
-address dangling links through a notification system [ref]:
+address dangling links through a notification system 
+[hill94extending-andalso-kappe95scalable]_:
 When a document is moved, a message is sent to servers storing links to it.
 Hyper-G uses an efficient protocol for delivering such notifications
 on the public Internet. 
@@ -109,11 +110,11 @@
 modifying them on each; when two people collaborate on a document, 
 sending each other versions of the document by email; 
 when someone downloads a document, modifies it, and publishes
-the modified version (e.g., a manual licensed under the Gnu FDL [ref]),
+the modified version (e.g., a manual licensed under the Gnu FDL [gnu-fdl]_),
 or when a group of people collaborate on a set of documents,
-synchronizing irregularly with a central server (as in CVS [ref]),
-a network (as in Lotus Notes [ref]) or directly with each other 
-(as in Groove[?] [ref]). In each of these cases, a user should be able
+synchronizing irregularly with a central server (as in CVS [cvs]_),
+with a network (as in Lotus Notes) or directly with each other.
+In each of these cases, a user should be able
 to work on the version at hand and then either merge it with others 
 or fork to a different branch.
 
@@ -122,7 +123,7 @@
 for storing and retrieving data as *blocks*, immutable
 byte sequences identified by cryptographic content hashes
 [lukka02guids]_. Additionally, Storm provides services
-for versioned data and Xanalogical storage [ref].
+for versioned data and Xanalogical storage [ted-xanalogical-structure-needed]_.
 We address the mobility of documents by block storage
 and versioning, while we use Xanalogical storage
 to address the movement of content between documents (copy&paste).
@@ -132,7 +133,7 @@
 peer-to-peer search technologies to enhance data mobility. 
 Additionally, we hope to 
 provide an input to the ongoing discussion about peer-to-peer
-hypermedia systems [ref ht01, ht02].
+hypermedia systems 
[thompson01coincidence-andalso-bouvin02open-andalso-p2p-hypertext-panel]_.
 
 Currently, Storm is partially implemented as a part of the Gzz 
 project [gzz]_, which uses Storm exclusively for all disk storage.
@@ -187,12 +188,12 @@
 ---------------------------------------
 
 The dangling link problem has received a lot of attention
-in hypermedia research [refs]. As examples, we examine the ways
-in which HTTP, Microcosm [ref] and Hyper-G [ref] 
+in hypermedia research (e.g. [davis98referential]_). As examples, we examine 
the ways
+in which HTTP, Microcosm [fountain90microcosm]_ and Hyper-G [andrews95hyperg]_ 
 deal with the problem.
 
 In HTTP, servers are able to notify a client that a document
-has been moved, and redirect it accordingly [ref spec?]. However,
+has been moved, and redirect it accordingly [rfc2068]_. However,
 this is not required, and there are no facilities for
 updating a link automatically when its target is moved.
 Consequently, broken links are a common experience for Web users.
@@ -201,7 +202,7 @@
 through *filters*, which react to arbitrary messages
 (such as 'find links to this anchor') generated by
 a client application. Filters are processes on the local system
-or on a remote host [ref distributed microcosm]. When
+or on a remote host [hill94extending]_. When
 a document is moved or deleted, a message is sent
 to the filters. Linkbases implemented as filters can
 update their links accordingly. A client selects a set
@@ -230,15 +231,15 @@
 it would be possible to find both the document and links to it,
 no matter which peer in the network they are stored on.
 
-Version control systems like CVS or RCS [ref] usually assume
+Version control systems like CVS or RCS [tichy85rcs]_ usually 
+run on a single system or assume
 a central server hosting a repository. The WebDAV/DeltaV protocols,
 designed for interoperability between version control systems, inherit
-this assumption [ref]. 
+this assumption [rfc2518-andalso-rfc3253]_. 
 
-On the other hand, Arch [ref] places all repositories
+On the other hand, Arch [arch]_ places all repositories
 into a global namespace and allows independent developers 
-to branch and merge overlapping repositories without any central control
-[is there a specific ref for this?].
+to branch and merge overlapping repositories without any central control.
 
 
 Peer-to-peer systems
@@ -248,11 +249,12 @@
 
 There are two major directions in peer-to-peer search systems,
 originally motivated by file-sharing systems like Napster.
-The more conventional one, flooding broadcasting networks [gnutella1, 
-kazaa, limewire, shareaza], forwards queries to all peers
+The more conventional one, flooding broadcasting networks 
+[gnutellaurl-andalso-ripeanu02mappinggnutella-andalso-kazaaurl]_, forwards 
queries to all peers
 reachable in a given number of hops (time-to-live).
-The second, distributed hashtables (DHTs) [chord, can, tapestry, pastry,
-kademlia, symphony, viceroy], stores (key,value) pairs which can be found given
+The second, distributed hashtables (DHTs) 
+[stoica01chord-andalso-ratnasamy01can-andalso-zhao01tapestry-andalso-rowston01pastry-andalso-maymounkov02kademlia-andalso-malkhi02viceroy]_
+stores (key,value) pairs which can be found given
 the key; a DHT assigns each peer a subset of all possible keys, and
 routes queries for a given key to the peer responsible for it.
 Before a pair can be found, it must be *inserted* in the DHT
@@ -279,11 +281,11 @@
 the peer responsible for them.
 
 A common API that can be supported by current and future DHTs
-is being proposed in [zhao02api].
+is being proposed in [zhao03api]_.
 
 Recently, a few DHT-like systems have been developed which employ
 a key space similarly to a DHT, but in which queries are routed
-to (key,value) pairs [SWAN, skip graph]: A peer 
+to (key,value) pairs [bonsma02swan-andalso-AspnesS2003]_: A peer 
 occupies several positions in the key space, one for each 
 (key,value) pair. In such a system, the indirection of placing
 close keys in the custody of a 'hashtable bucket' peer is removed
@@ -479,10 +481,9 @@
 representations of the block ids for file names).
 
 Many existing peer-to-peer systems could be used to
-find blocks on the network.
-For example, Freenet [freenet-ieee]_, recent Gnutella-based clients 
-(e.g. Shareaza [shareazaurl]_), and Overnet/eDonkey2000 [ref] 
-also use SHA-1-based identifiers [e.g. ref: magnet uri]. 
+find blocks on the network-- for example,
+Freenet [freenet-ieee]_,  or recent Gnutella-based programs 
+like Shareaza [shareazaurl]_.
 Implementations on top of a DHT could use both the
 directory and the home store approach as defined by [iyer02squirrel]_.
 
@@ -495,7 +496,7 @@
 Many practical problems have to be overcome before this
 implementation will be usable (for example seeding the
 table of known peers, and issues with UDP and network
-address translation [ref]).
+address translation [rfc3253]_).
 
 Sometimes it is useful to think about *zones* blocks are in,
 related to distribution policy: for example, a *public*
@@ -593,8 +594,7 @@
    the data is transcluded.
 
 Our current implementation shows only links between documents
-that are in memory at the same time [screenshot of xupdf, perhaps ref too
-(submitted) antont: was thinking the same, it would illustrate this well].
+that are in memory at the same time.
 In the future, we will implement a global distributed index at top of
 a distributed hashtable, with the scroll blocks' ids as the keys.
 To find the transclusions of a span, the system will retrieve
@@ -612,13 +612,9 @@
 One question raised by xanalogical storage is which links to show
 for a popular document that has been linked to by many users.
 We hope to address this problem by collaborative filtering
-of links [explain, ref (grouplens.org pubs?)]. There has been research on
+of links. There has been research on
 collaborative filtering in peer-to-peer systems
-without compromising participants' privacy [ref John Canny].
-For some purposes simple rules based on e.g. belonging to a group may be
-applicable as well: e.g. when working on a project with a project group, it
-may be beneficial for the members of the group to see other members'
-comments of articles etc.
+without compromising participants' privacy 
[canny02collaborative-andalso-canny02factor]_.
 
 
 Application-specific reverse indexing
@@ -784,17 +780,13 @@
 be wikis, which are collaboratively edited by anyone
 interested [leuf01wiki]_). It is not yet clear how to do this.
 Signing pointer blocks digitally may be sensible, but
-digital signatures require a public key infrastructure
-and a trusted timestamping mechanism [#]_, which
+digital signatures require a public key infrastructure, which
 is hardly feasible for a system intended to be used
 for off-line as well as on-line work.
 For long-term publishing, one-time signatures have been
-found useful [ref]. For the time being, the pointer mechanism
+found useful [anderson98erl]_. For the time being, the pointer mechanism
 works only in trusted Storm zones (Section 3), e.g.
 in a workgroup collaborating on a set of documents.
-
-.. [#] Without timestamps, digital signatures are only valid
-   for a limited time [ref].
 
 The ability to retain multiple 'current' versions of a document
 can be useful, for example when there is no time to consolidate