/[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.35 by benja, Sat Jan 25 13:11:48 2003 UTC revision 1.36 by benja, Sat Jan 25 17:51:33 2003 UTC
# Line 18  It's well recognized that references sho Line 18  It's well recognized that references sho
18    
19  ->  ->
20  On the Web, documents are tightly bound to one location: they  On the Web, documents are tightly bound to one location: they
21  cannot be moved to a different server without breaking links to them.  cannot be moved to a different server without breaking links to them[#]_.
22  This paradigm may be tolerable for published data, but it mixes  This paradigm may be tolerable for published data, but it mixes
23  badly with data on desktop computers, since users expect to  badly with data on desktop computers, since users expect to
24  move data quite freely, copying it through the network,  move data quite freely, copying it through the network,
25  taking it home on diskettes, sending it in e-mail attachments,  taking it home on diskettes, sending it in e-mail attachments,
26  or moving it between their desktop and laptop computers.  or moving it between their desktop and laptop computers.
27  Documents are copied from the Web to local storage for off-line reading.  Documents are copied from the Web to local storage for off-line reading.
28  We examine two issues this *data mobility* raises for hypermedia:  We present a design that addresses two issues
29    this *data mobility* raises for hypermedia:
30  keeping track of links, and keeping track of alternative versions  keeping track of links, and keeping track of alternative versions
31  as documents move between computers.  as documents move between computers.
32    
33    .. [#] Except if the new server is a complete replacement for the old,
34       inheriting its Internet domain.
35    
36  ->  ->
37  It is the norm for hypermedia systems to assume a centralized infrastructure,  It is the norm for hypermedia systems to assume a centralized infrastructure,
38  much like the Web. [Discuss Microcosm, Chimera and other OHS here.]  much like the Web. [Discuss Microcosm, Chimera and other OHS here.]
# Line 38  required permanent connection to a netwo Line 42  required permanent connection to a netwo
42  and, at least in its 1988 incarnation [ref Green] addressed data  and, at least in its 1988 incarnation [ref Green] addressed data
43  based on the address of a server holding a 'master copy.'  based on the address of a server holding a 'master copy.'
44    
 ->  
   
   
45  (To explain data mobility:  (To explain data mobility:
46  Data moves like this and that. The server/location paradigm  Data moves like this and that. The server/location paradigm
47  is not suited to this: To support hypermedia functionality correctly,  is not suited to this: To support hypermedia functionality correctly,
# Line 49  Only then can we merge the fragmented wo Line 50  Only then can we merge the fragmented wo
50  and online publishing into one.)  and online publishing into one.)
51    
52  Server centricity is what made the web scalable. Backlinks rejected  Server centricity is what made the web scalable. Backlinks rejected
53  for this reason [ref TBL]. However, recent innovations in P2P have made  for this reason [ref TBL -- XXX note: not true like this; the ref I had
54    in mind is http://www.w3.org/DesignIssues/NameMyth.html, and
55    it's not about back links]. However, recent innovations in P2P have made
56  scalable hashtables possible.  scalable hashtables possible.
57    
58    ->
59    Binding documents to servers has been necessary to make the Web scalable:
60    
61    
62    
63  {If standards could be agreed on, web servers should be able to  {If standards could be agreed on, web servers should be able to
64  self-organize into a DHT implementing bidi links. There has been  self-organize into a DHT implementing bidi links. There has been
65  interest in p2p hypermedia [ref Bouvin]. This would not, however,  interest in p2p hypermedia [ref Bouvin]. This would not, however,
# Line 94  This paper is structured as follows. Line 102  This paper is structured as follows.
102  2. Block storage  2. Block storage
103  ================  ================
104    
105    In our system, Storm (for *storage module*), all data is stored
106    in *blocks*, byte sequences identified by a
107    cryptographic hash. Blocks often have a similar granularity
108    as files, but they are immutable, since any change to the
109    byte sequence would change the hash (and thus create a different block).
110    
111    
112    
113  3. Xanalogical storage  3. Xanalogical storage
114  ======================  ======================
115    

Legend:
Removed from v.1.35  
changed lines
  Added in v.1.36

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