/[gzz]/manuscripts/storm/article.rst
ViewVC logotype

Diff of /manuscripts/storm/article.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.177 by antont, Sat Feb 15 17:11:35 2003 UTC revision 1.178 by benja, Sat Feb 15 17:13:58 2003 UTC
# Line 1008  would have to be sent through the networ Line 1008  would have to be sent through the networ
1008  Discussion  Discussion
1009  ==========  ==========
1010    
1011  In this section we evaluate Storm's design with regard to previously presented  To evaluate the design, we revisit the issues raised by data mobility.
1012  use cases, summarize Storm's implementation status and outline open issues  For the two issues addressed, *dangling links* and *tracking
 and future work.  
   
   
 Evaluation  
 ----------  
   
 To evaluate the design, the issues raised by data mobility are revisited in  
 the following. For the two issues addressed, *dangling links* and *tracking  
1013  alternative versions*, each individual (use) case that was identified in the  alternative versions*, each individual (use) case that was identified in the
1014  introduction is dealt with here to illustrate Storm.  introduction is dealt with here to illustrate Storm.
1015    
# Line 1075  as identifiers, verifyability is another Line 1067  as identifiers, verifyability is another
1067  of replication and caching combined with location-independent identifiers  of replication and caching combined with location-independent identifiers
1068  enable several improvements, including the possibility to keep on working on  enable several improvements, including the possibility to keep on working on
1069  shared documents even when there is no or an unreliable network connection.  shared documents even when there is no or an unreliable network connection.
   
 Future work  
 -----------  
   
 Currently, we are working on completing our GISP-based peer-to-peer  
 implementation of Storm. Once this is done, we intend to explore  
 alternative DHT implementations as well. We will also evaluate  
 using Merkle hash trees [XXXref] to identify blocks; this would  
 allow us to download parts of a block from multiple sources  
 simultaneously (as in e.g. [XXX ref Overnet]).  
   
 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 [vitali99versioning]_  
 notes that Xanalogical storage necessiates strong discipline in version tracking,  
 which current systems lack. One possibility is to take an existing system  
 (with features outside the focus of Gzz)  
 that implements strict versioning, and to modify it to use Storm for storage.  
 A candidate is the object-oriented (web) publishing environment Zope [ref zope.org/com, book,  
 article?], which is Free Software and stores everything by default as diffs to  
 a (flat file) database. Another way is studying the applicability of the  
 open hypermedia protocol (OHP) [reich-davis99-ohp].  
   
 As mentioned in the presentation of Storm block storage (section 4),  
 although the terminology used here is about characters and text, all media  
 are considered. There dealing with e.g. video data, with very large file  
 sizes, as (collections of) blocks, is partly unresolved.  
   
 Besides these issues with the backend, we are facing user interface issues  
 as well -- for example the conventions for listing, moving and deleting  
 blocks.  
   
 .. [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, see above ? -Hermanni]  
    Open issue: other related systems (within gzz?) for e.g. more synchronous  
    collabaration (irc?)?  
   
 .. [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  
    way, esp. when combined with multisource downloading (this can  
    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]  
 =======  
 >>>>>>> 1.173  
    The important point about p2p publishing is that no account and setup  
    is necessary to start publishing.  
1070        
1071    
1072  Conclusions  Conclusions
# Line 1164  it can be also used for private document Line 1085  it can be also used for private document
1085  does not support peer-to-peer distribution yet, but the Gzz project has used it  does not support peer-to-peer distribution yet, but the Gzz project has used it
1086  for local storage and server-based collaboration for one and a half years.  for local storage and server-based collaboration for one and a half years.
1087    
1088    Currently, we are working on completing our GISP-based peer-to-peer
1089    implementation of Storm. Once this is done, we intend to explore
1090    alternative DHT implementations as well. We will also evaluate
1091    using Merkle hash trees [XXXref] to identify blocks; this would
1092    allow us to download parts of a block from multiple sources
1093    simultaneously (as in e.g. [XXX ref Overnet]).
1094    
1095  Storm has proven to be a solid basis for Gzz, but  Storm has proven to be a solid basis for Gzz, but
1096  no work has been done to integrate it with existing systems, yet.  no work has been done to integrate it with existing systems, yet.
1097  This makes Storm a rather monolithic approach at present.  This makes Storm a rather monolithic approach at present.
# Line 1172  should be hard to integrate with existin Line 1100  should be hard to integrate with existin
1100  we believe that it is valuable as an exercise in what is possible  we believe that it is valuable as an exercise in what is possible
1101  if we can break backwards compatibility with the state of the art.  if we can break backwards compatibility with the state of the art.
1102    
1103    No work on integrating Storm with current programs (in the spirit of Open
1104    Hypermedia) has been done so far. It is not clear how far this is possible
1105    without changing applications substantially, if advantage of our
1106    implementation of Xanalogical storage is to be taken. Vitali [vitali99versioning]_
1107    notes that Xanalogical storage necessiates strong discipline in version tracking,
1108    which current systems lack. One possibility is to take an existing system
1109    (with features outside the focus of Gzz)
1110    that implements strict versioning, and to modify it to use Storm for storage.
1111    A candidate is the object-oriented (web) publishing environment Zope [ref zope.org/com, book,
1112    article?], which is Free Software and stores everything by default as diffs to
1113    a (flat file) database. Another way is studying the applicability of the
1114    open hypermedia protocol (OHP) [reich-davis99-ohp].
1115    
1116  At the end, we hope that we have provided a case study in  At the end, we hope that we have provided a case study in
1117  what's possible in a system that does not use  what's possible in a system that does not use
1118  location-dependent identifiers at all. We hope to raise awareness  location-dependent identifiers at all. We hope to raise awareness

Legend:
Removed from v.1.177  
changed lines
  Added in v.1.178

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26