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.] |
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, |
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, |
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 |
|
|