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 |
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 |