[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 05:06:47

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

Log message:
        Remove comments from thesis branch I won't address before the deadline

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/benja-diff-fa/thesis.rst.diff?tr1=1.2&tr2=1.3&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.2 
gzz/Documentation/misc/benja-diff-fa/thesis.rst:1.3
--- gzz/Documentation/misc/benja-diff-fa/thesis.rst:1.2 Sun Feb  9 04:44:07 2003
+++ gzz/Documentation/misc/benja-diff-fa/thesis.rst     Sun Feb  9 05:06:47 2003
@@ -2,6 +2,9 @@
 Storm: Supporting data mobility through location-independent identifiers
 ========================================================================
 
+:Author: Benja Fallenstein
+
+
 1. Introduction
 ===============
 
@@ -154,9 +157,6 @@
     Pointers.c = z1 + (15, 25);
     Diffs.c = z1 - (15, 15);
 
-.. [Use cases in intro, discussion on how Storm applies to them
-   to the end/in Conclusions.]
-
 
 2. Related Work
 ===============
@@ -169,8 +169,6 @@
 in which HTTP, Microcosm [ref] and Hyper-G [ref] 
 deal with the problem.
 
-.. XXX and URNs [ref]
-
 In HTTP, servers are able to notify a client that a document
 has been moved, and redirect it accordingly [ref spec?]. However,
 this is not required, and there are no facilities for
@@ -188,14 +186,6 @@
 of remote filters to use. Only links stored by one
 of these filters can be found by the client.
 
-.. [HymEbook?]
-
-.. Microcosm systems can independently choose 
-   whether to import filters from other systems, and whether
-   to host and export own filters; thus, a system can act
-   as both a client and server at the same time,
-   for example in a workgroup.
-
 In Hyper-G, documents are bound to servers, and a link
 between documents on different servers is stored by both servers
 [kappe95scalable]. This ensures that all links from and to a document
@@ -218,8 +208,6 @@
 it would be possible to find both the document and links to it,
 no matter which peer in the network they are stored on.
 
-.. XXX Say something about the usual resolvable URN approaches
-
 
 2.2. Alternative versions
 -------------------------
@@ -340,18 +328,6 @@
 a *home-store* and the latter a *directory* scheme (they call the peer
 responsible for a hashtable item its 'home node,' thus 'home-store').
 
-.. Should we discuss applications of p2p systems (CFS, OceanStore, Squirrel, 
...)
-   here? If so, which ones?
-
-.. thesis-benja: remove paragraph below
-
-CFS [ref], which is built upon Chord DHT peer-to-peer routing layer[ref], 
stores 
-data as blocks. However, CFS *splits* data (files) into several miniblocks and 
-spreads blocks over the available CFS servers. Freenet [ref] and PAST [ref],
-which is based on Pastry [ref], do not split files into blocks, since they 
store data 
-as whole files. All previously mentioned systems lack of the immutable 
-property which is used in Storm blocks.
-
 Recently there has been some interest in peer-to-peer hypermedia.
 Thompson and de Roure [ref ht01] examine the discovery
 of documents and links available at and relating to
@@ -450,24 +426,9 @@
 permanently downloaded to the local harddisk, it can be found
 by a browser just as data from the network. This is convenient 
 for offline browsing, for example in mobile environments:
-After a document has been downloaded, links to it will *never*
+After a document has been downloaded, links to it will not
 cease to work, online or offline.
 
-.. tried to think this a bit, as 'never' is always a strong word.
-   can it be that data in the cache is 'out-of-sync', i.e. 
-   there are different versions so that links indeed break for 
-   off-line browsing? e.g. when there is document A linking 
-   to document B, both v1.0, and the user downloads them. then,
-   both are updated on the server, to versions 1.1. user dowloads
-   A, goes off-line, and tries to follow the link to B(1.1?). ? 
-   i know this is not what is meant above, but yet an example of how 
-   evil reviewers might react to the strong notion 'never' there ;o
-   or is it so that the link from A to B is not to a particular version,
-   but to any B, so that in that case the user would get B1.0 and be happy?
-   (or confused, if diff from A,B1.0->1.1 was so major that how A1.1 links to
-   B1.1 does not make any sense when the user ends up in 1.0 instead?)
-   -- antont
-
 Thirdly, immutable blocks increase *reliability*. 
 When saving a document, an application will only *add* blocks,
 never overwrite existing data. When a bug causes an application
@@ -682,19 +643,6 @@
 systems that allow range queries, such as skip graphs [ref] 
 and skipnet [ref], may prove useful.
 
-.. [how does video work here, i.e. are they huge blocks or collections of many
-   small, frames? or a sequence between two keyframes?]
-
-   Benja says: Probably large, but the number of links to them 
-   still won't be that big, I guess. Not sure how to discuss this
-   in the text; feel free to propose something :-)
-
-   Toni: will try.. wondering also about who to consult :o
-
-.. [This might be relevant also:
-   http://www.hpl.hp.com/techreports/2002/HPL-2002-209.pdf
-   -Hermanni]
-
 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
@@ -781,13 +729,6 @@
 are able to scale to the load to store an item for each word
 occuring in a document.
 
-.. [There are two refs about keywords in DHTs-- should we ref these ? 
-Hermanni]
-
-   Not sure how applicable they are: our system is *not*
-   as general or performant as a DHT (as explained above).
-   Should read & find out whether they could be implemented
-   through our index system at all... -b
-
 
 6. Versioning
 =============
@@ -803,8 +744,6 @@
 Through this mechanism, we can keep old versions of documents
 along with the current versions.
 
-.. [Figure ? -Hermanni]
-
 Secondly, in the spirit of version control systems like CVS,
 we do not store *each version*, but only the differences between versions.
 However, we still refer to each full version by the id of a block
@@ -813,7 +752,6 @@
 using the differences, and then check the result using
 the cryptographic hash in the full version's block id.
 
-.. [Figure ? -Hermanni]
 
 6.1. Pointers: implementing mutable resources
 ---------------------------------------------
@@ -916,8 +854,6 @@
 between alternative current versions; and the suitability
 for Web-like publishing. More research is needed in this area.
 
-.. authenticating -> [possible refs: ConChord, SDSI/SPKI ? -Hermanni]
-
 
 6.2. Diffs: storing alternative versions efficiently
 ----------------------------------------------------
@@ -1093,6 +1029,13 @@
 Storm has proven to be a solid basis for Gzz, but
 no work has been done to integrate it with existing systems, yet.
 This makes Storm a rather monolithic approach at present.
+No work on integrating Storm with current programs (in the spirit of Open
+Hypermedia) has been done so far. It is not clear how far this is possible
+without changing applications substantially, if advantage of our
+implementation of Xanalogical storage is to be taken.  (Vitali [ref] notes
+that Xanalogical storage necessiates strong discipline in version tracking,
+which current systems lack.)
+
 However, even if Storm-- or especially Xanalogical storage--
 should be hard to integrate with existing systems,
 we believe that it is valuable as an exercise in what is possible
@@ -1103,3 +1046,9 @@
 location-dependent identifiers at all. We hope to raise awareness
 for the prospects of location-independent systems based
 on structured overlay networks like DHTs.
+
+
+8. References
+=============
+
+XXX
\ No newline at end of file