/[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.132 by hemppah, Wed Feb 12 12:35:18 2003 UTC revision 1.133 by antont, Wed Feb 12 12:39:34 2003 UTC
# Line 1120  would have to be sent through the networ Line 1120  would have to be sent through the networ
1120  7. Experience and future directions  7. Experience and future directions
1121  ===================================  ===================================
1122    
 Review of the use cases: what does storm in each? --  
 [ MOVE TO EARLIER PART, SEE ABSTRACT ]  
   
 (where&how to put this, if use cases are used like this at all?  
 agreed with benja on irc that we might try this approach - hinting about the  
 use cases early on and taking a detailed look later, in light of the design.)  
   
1123  evaluation  evaluation
1124  ----------  ----------
1125    
1126  To evaluate the design, the issues raised by data mobility are revisited in  To evaluate the design, the issues raised by data mobility are revisited in
1127  the following. For the two issues addressed, *danglink links* and *tracking  the following. For the two issues addressed, *danglink links* and *tracking
1128  alternative versions*, each individual (use) case that was identified in the  alternative versions*, each individual (use) case that was identified in the
1129  introduction is used here to illustrate Storm.  introduction is dealt with here to illustrate Storm.
1130    
1131  *Dangling links*. When documents are moved between servers, when using Storm  *Dangling links*. When documents are moved between servers, when using Storm
1132  the links to them are not affected as the identifiers are  the links to them are not affected as the identifiers are
# Line 1141  location-independent. In a peer-to-peer Line 1134  location-independent. In a peer-to-peer
1134  id returns a location where the data is currently available. If the  id returns a location where the data is currently available. If the
1135  publisher removes the document permanently, but it is archived elsewhere,  publisher removes the document permanently, but it is archived elsewhere,
1136  the archives act as peers similarly. When there is no network connection  the archives act as peers similarly. When there is no network connection
1137  available, but a local copy instead, the lookup points to that.  available, but a local copy instead, the lookup points to that. If a
1138    document and a link to it are received independently, e.g. as attachments in
1139  1. live meeting:  separate e-mails, or a link to a document in the local intranet is e-mailed,
1140  Documents have been assigned block-ids (and urns?) at creation.  (all those links work :o .. this was also discussed in intro already (index))
1141  Pools that are shared / set visible for the other user show over the  When people meet live, e.g. on a train, and form an ad-hoc network, they are
1142  network. (...)  able to see each other's documents and follow links to them if a
1143    peer-to-peer implementation of Storm is used (and pools published
1144  2. syncing via a remote connection after working separately:  accordingly..? what should be discussed here?).
 Both new versions are actually diffs to the original. Merging is  
 application-specific.  
   
 3. publising on/from the laptop:  
 B sets the document public (how that is done depends on UI implementation),  
 i.e. putting in a published pool, which may reside locally or externally  
 e.g. on a (dedicated) server that is "always-on". These public/private zones  
 are an area where future research is needed, possibly related to rights and  
 permissions etc. too.  
   
 4. A and other people viewing, commenting, bookmarking, linking:  
 When someone views the document, the system retrieves the datablock.  
 Comments may be new entities(?) linking to it, editing would create a new  
 version as a diff as a new datablock with a new guid. Bookmarks and links to  
 the original are made to the ID of the original, with no trace of the  
 location (originally B's laptop). (more info about pointers here, and in the  
 next one?)  
   
 5. When B takes her laptop off-line, the searches for the ID of her (and  
 A's) Document simply result pointing at the other copies (e.g. on A's  
 machine).  
   
 6. Increasing traffic: The peer-to-peer network can automatically share the  
 load, as popular items get replicated and further delivered from different  
 hosts. (does storm actually do this / is it aimed at this?)  
   
 7. When B reconnects, can check comments to the Document etc? How does that  
 happen? Index?  
1145    
1146    *Tracking alternative versions*. Because Storm utilises immutable blocks,
1147    each modification to a document creates a new block. When a document is
1148    modified on several independent, unconnected systems, if there are
1149    simultaneous changes (i.e. no synching in between), there will be several  
1150    versions of it. Using diffs, each version is actually (a collection of)
1151    changes to the original. What happens then, is outside the scope of Storm:  
1152    the authors may decide to merge the changes forming a new joint version, but
1153    how that is done is file format and hence application specific. If (some of)
1154    the new versions of the document are not merged but forked to separate
1155    branches, they simply continue to exist (they may be assigned different
1156    names, which is again outside the scope of Storm).
1157    
1158    .. some things from the earlier treatment left here as notes:
1159    
1160       B sets the document public (how that is done depends on UI
1161       implementation), i.e.  putting in a published pool, which may reside
1162       locally or externally e.g.  on a (dedicated) server that is "always-on".
1163       These public/private zones are an area where future research is needed,
1164       possibly related to rights and permissions etc. too.
1165      
1166       Comments may be new entities(?) linking to it  
1167    
1168    
1169  Open issue: Tree hashing, also possibly needed for (OceanStore-like?)  Open issue: Tree hashing, also possibly needed for (OceanStore-like?)
1170  distribution of shares  distribution of shares

Legend:
Removed from v.1.132  
changed lines
  Added in v.1.133

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