From the paper review: - Cryptographic hash not unique (says reviewer) - P2P is not "emerging" [[ but structured overlays are!! ]] - system is in too early stage for implementation report article - issues are interesting, but other pressing issues are: provenance, rights management, accountability - "With regards the Storm Block Storage section, the choice of language and use of unexplained side-comments are frustrating. Storm proposes the xanalogical approach of `chunking` content into immutable blocks that are identified by one-way hashes of their content. However, this introduces other pressing user problems, including how one finds a document when it`s identifier is a 160-bit hexadecimal string, and how policy models can be extended to cover multiple layers of content (blocks, updated - and thus different - blocks, documents, etc.)" - unclear how documents are named, discovered, and navigated - implementation and indexing sections: should have examples of API use + descriptions what the operations mean - persistency commitment: not related to TBL's persistent URI writeup - explain what SHA-1 is - how is indexing used? (which apps put things into the index?) - how to integrate Storm into the Web? Eric Armstrong: - Explain "cryptographic hash": non-colliding hash; give reference - Explain the relationship between 'block,' 'document,' 'hash'-- "how are documents hashed?" - Storage space impact of storing past versions of documents? (Answer: Diffing and deleting) - A proposed "file system" gui will be different from a shell: not able to simply launch an editor, right? (Possibility: CVS-like think o'top Storm ["Cool. Just mentioning that will probably lead to some getting excited enough to do it..."]) - What's "structured overlay networks"? - Dangling (unresolved) links and keeping track of alt. versions need to go into the abstract - Which part of the related work is: old work moved beyond; old work providing lessons; foundation for current work; predecessors or clients of current work? - Mention Fenfire and its relationship to Storm here - What do we want to do with common DHT API-- build on it, rival it, go beyond it? - "Probabilistic access seems reasonable for "contact" scenarios (bunch of people together at a meeting), but not for "publishing" scenarios (publish document on the web). May be worth drawing the distinction here." - Several problems related to Xu storage section: >> Overview of Xanalogical Storage >> * This threw me. A minute ago we were talking about blocks, >> now we're talking about characters. Needs a transition to >> make the relationship apparent. (Later, you talk about >> spans. Those may be precursors to blocks or they really are >> blocks. I'm not sure which. Need to anticipate that thought >> somehow, and tell how we're building up to it, if that's >> what's going on >> >> * Yeah. There's the paragraphs on spans. That threw me, too. >> Suddenly I had gone from blocks to characters and now to >> spans, and I was pretty confused about how they related. >> >> * "Our current implementation" has me wondering what we're >> talking about. At this point, I thought this more "Related >> work", like "peer to peer systems". But now it seems it's >> all one system? Or was this a previous system, before you >> started working on Storm? (Need to make the relationships >> apparent.) All this makes me think we should give "Xanadu" a section in "Related Work," and then later explain how we explain xanalogical storage in Storm, in a different way than Project Xanadu did. - "Storm Block Storage * Now were back to blocks. Why did that last section exist, anyway? (make the relationship apparent)" - Explain what "(im)mutable data structures" have to do with "versioning." Clue in: a) In a normal caching system, when a new version is created... b) That means that the system has to... c) But in Storm... - Explain external links: Anybody can contribute links without changing the linked document. - suggestion: move xu section after block storage section to remove back-and-forth - Explain very shortly how Fenfire is explicitly developed to overcome the limitations of traditional file-based applications-- what these limitations are, and how Fenfire tries to solve them. - Switch indexing and versioning sections, so that versioning is the motivation for indexing. - Explanation of 'obsoleted list' not clear enough in pointer section. - Storing diffs vs. intact versions: You can do it either way. - "UI conventions for listing moving, and deleting blocks:" The user should be able to think about *documents*, not blocks. The UI should be for moving docs. - **"Version of a block" doesn't exist** - It's good to state points for further research in pointers - Explain that there can be reliability benefits from not storing the current version along diffs: If you reconstruct the current version through the diffs every time, you'll notice when one of your diffs goes awry and the reconstruction breaks. Explain that we provide both ways, your choice. (Eric: "Excellent point! The example was really good, too. I've changed my mind. The way you're doing it is right. (If there is room for the example to explain why, awesome!)") - Explain how Storm saves disk storage when showing the same image or movie scene in many places. - Conclusions: what's an "OHP"? (define) - Define Zope, too