[Gzz-commits] manuscripts/storm article.rst

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Hermanni Hyytiälä <address@hidden>      03/02/13 08:08:38

Modified files:
        storm          : article.rst 

Log message:
        Modified discussion section, made suggestions for excluding/including 
issues/future work

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.137 manuscripts/storm/article.rst:1.138
--- manuscripts/storm/article.rst:1.137 Wed Feb 12 11:41:06 2003
+++ manuscripts/storm/article.rst       Thu Feb 13 08:08:38 2003
@@ -486,8 +486,34 @@
    documents-- or different versions of a document-- is only
    stored once, in a block only referred to wherever
    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].
+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
+all transclusions of any span in the scroll block, then
+sort out those that do not overlap the span in question.
 
+Since the problem is to search for overlapping ranges,
+the spans cannot be used as hashtable keys. However, as the blocks
+will be relatively small (limited by the amount of text
+the user enters between two saves of a document), we hope
+that this will not be a major scalability problem. Otherwise,
+systems that allow range queries, such as skip graphs [ref], 
+skipnet [ref], may prove useful.
 
+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
+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.
 
 4. Storm block storage
 ======================
@@ -1131,75 +1157,27 @@
    These public/private zones are an area where future research is needed,
    possibly related to rights and permissions etc. too.
    
-   Comments may be new entities(?) linking to it   
-
+   Comments may be new entities(?) linking to it
 
-7.2 Status, open issues and future work
------------------------------------
-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].
-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
-all transclusions of any span in the scroll block, then
-sort out those that do not overlap the span in question.
-
-Since the problem is to search for overlapping ranges,
-the spans cannot be used as hashtable keys. However, as the blocks
-will be relatively small (limited by the amount of text
-the user enters between two saves of a document), we hope
-that this will not be a major scalability problem. Otherwise,
-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 :-)
+[At the end of this section ? -Hermanni]
+When Xanalogical storage is not applied, using Storm as a
+replacement/equivalent of a conventional file and versioning system is
+trivial?    
 
-   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]
+7.2 Status, open issues and future work
+---------------------------------------
 
-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
-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.
-   
-   
-Open issue: Tree hashing, also possibly needed for (OceanStore-like?)
-distribution of shares
 
-Open issue: We want to be able
+[worth to mention, security in general ? -Hermanni]
+1) Open issue: We want to be able
 to copy the blocks from the NYT publication pool to our local computer
 and verify offline that it really comes from NYT. How to do this will go
 into the article as an open research question ;-)
 
-Future directions: of course, we should implement a prototype
+2) Open issue: identification of online entities ?
 
-Open issue/Future directions: implement multisource downloading
-
-Future directions: Implement home node model or directory model ?
-
-Open issue: Firewall Transparency/NATs ?
-
-Open issue: identification of online entities ? 
-
-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?)?
+[worth to mention ? -Hermanni]
 
 .. moved the following here from intro, as suggested by (b&) Hermanni
 
@@ -1210,6 +1188,7 @@
 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
    combinations of Gzz/Storm and the Object-Oriented Web publishing
    environment Zope [ref zope.org/com, book, article?]. For example, Storm
@@ -1222,20 +1201,52 @@
    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?)
    Benja also noted about pointing to external data? (couldn't find the post
    from the archives)
 
+[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
+
+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
+   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
+
+[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: 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 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)
 
-When Xanalogical storage is not applied, using Storm as a
-replacement/equivalent of a conventional file and versioning system is
-trivial? 
-
+[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
@@ -1244,14 +1255,18 @@
    potentially boost download speeds to the full available bandwidth).
    This is a performance/reliability issue rather than something
    changing the fundamental qualities of the network, but still important.
-   
+ 
+[not worth to mention ? -Hermanni]  
    [Symphony supports heterogeneity of peers -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]
    One possibility: Use IBP for limited-time publishing, referring to
-   the location through the DHT? This might be related to p2p publishing.
+   the location through the DHT? This might be related to p2p publishing.   
+
    
 
 8. Conclusions