[Gzz-commits] manuscripts/storm SCRATCH article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/01/26 11:25:24

Modified files:
        storm          : SCRATCH article.rst 

Log message:
        Work today so far

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/storm/SCRATCH.diff?tr1=1.3&tr2=1.4&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/storm/article.rst.diff?tr1=1.38&tr2=1.39&r1=text&r2=text

Patches:
Index: manuscripts/storm/SCRATCH
diff -u manuscripts/storm/SCRATCH:1.3 manuscripts/storm/SCRATCH:1.4
--- manuscripts/storm/SCRATCH:1.3       Fri Jan 24 09:23:50 2003
+++ manuscripts/storm/SCRATCH   Sun Jan 26 11:25:23 2003
@@ -1,4 +1,12 @@
 
+NOTE:
+a name is dereferencable (a block can be found) as long as
+there is a server holding it. therefore, quality of service
+*can* be 'bought' as needed.
+
+
+
+
 Many hypermedia systems place each document and link in the custody
 of one server, rendering it unusable when connectivity fails.
 For example, on the web, when connection to a server fails,
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.38 manuscripts/storm/article.rst:1.39
--- manuscripts/storm/article.rst:1.38  Sat Jan 25 16:51:38 2003
+++ manuscripts/storm/article.rst       Sun Jan 26 11:25:23 2003
@@ -138,14 +138,45 @@
 We have implemented the first three (using hexadecimal
 representations of the block ids for file names).
 
+Storing all data in Storm blocks provides *reliability*:
+When saving a document, an application will only *add* blocks,
+never overwrite existing data. When a bug causes an application
+to write malformed data, only the changes from one session
+will be lost; the previous version of the data will still
+be accessible. This makes Storm well suited as a basis
+for implementing experimental projects (such as ours).
+
 When used in a network environment, Storm ids do not provide
 a hint as to where in the network the matching block can be found.
 However, current peer-to-peer systems could be used to
 find blocks in a distributed fashion; for example, Freenet [ref]
 and some Gnutella clients [ref] also use SHA-1-based identifiers.
+However, we have not put a network implementation into regular use
+yet and thus can only describe our design, not report on
+implementation experience.
 We discuss peer-to-peer implementations in Section 6, below.
 
-The immutability of blocks makes caching trivial, since
+The immutability of blocks should make caching trivial, since it is
+never necessary to check for new versions of blocks.
+Since the same namespace is used for local data and data
+retrieved from the network, online documents that have been
+permanently downloaded to the local harddisk can also be found
+by the caching mechanism. This is convenient for offline browsing,
+for example in mobile environments: Users can download documents
+while they are online, store them locally, and be sure that
+their software will be able to access them as if downloaded
+from the net, without broken links.
+
+Given a peer-to-peer distribution mechanism, it would be possible
+to retrieve blocks from any peer online that has a copy
+in its cache or permanent storage. This is similar to the Squirrel
+web cache [ref], but does not require trust between the peers,
+since it is possible to check the blocks' cryptographic hashes.
+Since much-requested blocks would be cached on many systems,
+such a network could deal with XXX much more easily.
+On the other hand, there are privacy concerns with exposing
+one's browser cache to the outside world.
+
 
 
 That all data is stored in blocks means that links to it