gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz-commits] manuscripts/storm TODO article.rst style.tex


From: Benja Fallenstein
Subject: [Gzz-commits] manuscripts/storm TODO article.rst style.tex
Date: Fri, 14 Feb 2003 13:16:39 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/14 13:16:39

Modified files:
        storm          : TODO article.rst 
Added files:
        storm          : style.tex 

Log message:
        Fix rst syntax, UML captions

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/storm/style.tex?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/storm/TODO.diff?tr1=1.4&tr2=1.5&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/storm/article.rst.diff?tr1=1.146&tr2=1.147&r1=text&r2=text

Patches:
Index: manuscripts/storm/TODO
diff -u manuscripts/storm/TODO:1.4 manuscripts/storm/TODO:1.5
--- manuscripts/storm/TODO:1.4  Thu Feb 13 08:48:08 2003
+++ manuscripts/storm/TODO      Fri Feb 14 13:16:39 2003
@@ -9,3 +9,4 @@
   or let them be in current form but finish them (make complete&correct) 
[antont]
 - discuss current status [benja]
 - discuss how xu storage is related to data mobility [benja]
+- discuss URN-5 [benja]
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.146 manuscripts/storm/article.rst:1.147
--- manuscripts/storm/article.rst:1.146 Fri Feb 14 10:46:38 2003
+++ manuscripts/storm/article.rst       Fri Feb 14 13:16:39 2003
@@ -74,7 +74,7 @@
 but there is a local copy (e.g. on a laptop or dialup system);
 or when the publisher removes a document permanently,
 but there are still copies (e.g. in a public archive such as
- [waybackmachine]_). Dangling links are also an issue
+[waybackmachine]_). Dangling links are also an issue
 when a document and a link to it are received independently,
 for example as attachments to independent emails,
 or when a link is sent by mail and the document is available
@@ -147,6 +147,7 @@
 Section 8 concludes the paper.
 
 .. uml:: storm_layers
+    :caption: The Storm model
 
     package Blocks
 
@@ -867,6 +868,7 @@
 about pointer ``P``, we can quickly find out the current one.
 
 .. uml:: storm_pointers
+    :caption: UML diagram of Storm pointers
 
     class Pointer
 
@@ -1059,6 +1061,7 @@
 and computing and applying differences.
 
 .. uml:: version_interfaces
+    :caption: UML diagram of the diff interfaces
 
     class Version "interface"
         methods
@@ -1196,8 +1199,9 @@
 notes that Xanalogical storage necessiates strong discipline in version 
tracking,
 which current systems lack.) 
 
-[worth to mention ? -Hermanni]
-.. An idea for future work in this area is investigating potential
+
+.. [worth to mention ? -Hermanni]
+   An idea for future work in this area is investigating potential
    combinations of Gzz/Storm and the Object-Oriented Web publishing
    environment Zope [ref zope.org/com, book, article?]. For example, Storm
    might be used as a storage module for Zope (instead or combined with the
@@ -1209,23 +1213,25 @@
    for the (even substantial) changes that 'xanalogicalising' it would mean
    in practise. For Gzz, Zope might provide a window to the Web.
 
-[worth to mention ? -Hermanni]
-.. interestingly zope by default stores diffs in the zodb 
(similarly:cvs&storm?)
+.. [worth to mention ? -Hermanni]
+   interestingly zope by default stores diffs in the zodb 
(similarly:cvs&storm?)
    Benja also noted about pointing to external data? (couldn't find the post
    from the archives)
 
-[worth to mention ? -Hermanni]
+.. [worth to mention ? -Hermanni]
+
 design&impelement p2p functionality, where Symphony and Kademlia potential 
alternativies
 for DHT overlay
    
-[worth to mention, fetching data etc. ? -Hermanni]
-1) Open issue: Tree hashing, also possibly needed for (OceanStore-like?)
-distribution of shares
+.. [worth to mention, fetching data etc. ? -Hermanni]
+
+1. Open issue: Tree hashing, also possibly needed for (OceanStore-like?)
+   distribution of shares
+2. Open issue/Future directions: implement multisource downloading
 
-2) Open issue/Future directions: implement multisource downloading
 
-[not worth to mention ? -Hermanni]
-.. [how does video work here, i.e. are they huge blocks or collections of many
+.. [not worth to mention ? -Hermanni]
+   [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 
@@ -1234,28 +1240,28 @@
 
    Toni: will try.. wondering also about who to consult :o
 
-[not worth to mention ? -Hermanni]
-Future directions: Implement home node model or directory model ?
+.. [not worth to mention ? -Hermanni]
+   Future directions: Implement home node model or directory model ?
 
-[not worth to mention ? -Hermanni]
-Open issue: Firewall Transparency/NATs ?
+.. [not worth to mention ? -Hermanni]
+   Open issue: Firewall Transparency/NATs ?
 
-[not worth to mention ? -Hermanni]
-Open issue: notes in the text about block sizes with video
+.. [not worth to mention ? -Hermanni]
+   Open issue: notes in the text about block sizes with video
 
-[not worth to mention, see above ? -Hermanni]
-Open issue: other related systems (within gzz?) for e.g. more synchronous
-collabaration (irc?)?
+.. [not worth to mention, see above ? -Hermanni]
+   Open issue: other related systems (within gzz?) for e.g. more synchronous
+   collabaration (irc?)?
 
-[not worth to mention, see above OpenHyp paragraph ? -Hermanni]
-.. Investigating the degrees of interoperability with Open Hypermedia
+.. [not worth to mention, see above OpenHyp paragraph ? -Hermanni]
+   Investigating the degrees of interoperability with Open Hypermedia
    (/Structural Computing?) and (more primitive?) other (Web) XXX is a possible
    direction for future work, and will be preliminarly discussed here too.
    [benja says: Really? Do we/can we discuss that really? antont: 'll try.]
    (checked OHProtocol, no fruit there yet)
 
-[not worth to mention, first p2p proto then these ;) ? -Hermanni]
-.. p2p -> cf half-life of peers (Mojo Nation): Is it desirable that 'weak' 
peers
+.. [not worth to mention, first p2p proto then these ;) ? -Hermanni]
+   p2p -> cf half-life of peers (Mojo Nation): Is it desirable that 'weak' 
peers
    participate in a DHT? -- In Circle, peers must have been online
    for at least an hour... In which ways, then, can 'weak' peers contribute
    to the network in a p2p fashion? Caching is certainly one central
@@ -1264,14 +1270,14 @@
    This is a performance/reliability issue rather than something
    changing the fundamental qualities of the network, but still important.
  
-[not worth to mention ? -Hermanni]  
+.. [not worth to mention ? -Hermanni]  
    [Symphony supports heterogeneity of peers -Hermanni]
 
-[not worth to mention ? -Hermanni]
+.. [not worth to mention ? -Hermanni]
    The important point about p2p publishing is that no account and setup
    is necessary to start publishing.
 
-[not worth to mention ? -Hermanni]
+.. [not worth to mention ? -Hermanni]
    One possibility: Use IBP for limited-time publishing, referring to
    the location through the DHT? This might be related to p2p publishing.   
 
@@ -1324,3 +1330,8 @@
 
 Harri Oinas-Kukkonen, observations (overall, about benefits, presentation)
 
+
+References
+==========
+
+.. bibliography:: ../gzigzag ../p2p
\ No newline at end of file




reply via email to

[Prev in Thread] Current Thread [Next in Thread]