[Gzz-commits] manuscripts/storm article.rst

[Toni Alatalo]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Toni Alatalo <address@hidden>   03/02/08 07:17:59

Modified files:
        storm          : article.rst 

Log message:
        misc work, will need to re-check

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.110 manuscripts/storm/article.rst:1.111
--- manuscripts/storm/article.rst:1.110 Fri Feb  7 22:56:49 2003
+++ manuscripts/storm/article.rst       Sat Feb  8 07:17:59 2003
@@ -372,6 +372,21 @@
 After a document has been downloaded, links to it will *never*
 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
@@ -541,6 +556,8 @@
    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]
@@ -551,6 +568,10 @@
 of links [explain, ref (grouplens.org pubs?)]. 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.
 
 
 5. Indexing
@@ -684,7 +705,9 @@
 
     +---------+ 1      * +---------------+
     | Pointer |----------| Pointer block |
-    +---------+          +---------------+
+    +---------+          +===============+
+                         |list: obsoleted| 
+                         +---------------+
                                * |
                                  | 
                                  |
@@ -901,13 +924,13 @@
 differences between data item's key and peer's key), which each peer provides 
 along the routing path.
 
-Of course, there are major differences within approaches. For DHT approach, 
-perhaps the biggest difference is the fact *what* is self-organized into 
+Obviously, there are major differences within approaches. For the DHT 
approach, 
+perhaps the main difference is *what* is self-organized into a
 virtual key space. For instance, in SWAN [ref] and Skip Graph [ref], *data 
-items* self-organise into  virtual address space, while in other DHT 
-implementations *peers* self-organise in structured form in virtual space. 
-In broadcasting approach, implementations' differences mostly lie in the 
-*structural level* of overlay network, i.e. super peers and peer clusters.
+items* self-organise into a virtual address space, while in other DHT 
+implementations *peers* self-organise in structured form in a virtual space. 
+In the broadcasting approach, implementations' differences mostly lie in the 
+*structural level* of the overlay network, i.e. super peers and peer clusters.
 
 .. (Probabilistic access to documents may be ok in e.g. workgroups,
    but does not really seem desirable. (At the ht'02 panel, Bouvin
@@ -1001,6 +1024,11 @@
 Benja also noted about pointing to external data? (couldn't find the post
 from the archives)
 
+Open issue: notes in the text about block sizes with video
+
+Open issue: other related systems (within gzz?) for e.g. more synchronous
+collabaration (irc?)?
+
 
 9. Conclusions
 ==============
@@ -1017,4 +1045,9 @@
    exposing one's cache-- duh, but I for one hadn't thought
    about it! And the Squirrel paper doesn't mention it either.
    Probably it's pointed out somewhere in the literature--
-   too basic a problem not to have been noticed-- but still... -b)
\ No newline at end of file
+   too basic a problem not to have been noticed-- but still... -b)
+
+Erno Kuusela for comments (will check those from SCRATCH and ask him to read
+a current version also)
+
+Harri Oinas-Kukkonen, observations (overall, about benefits, presentation)
\ No newline at end of file