5 |
1. Introduction |
1. Introduction |
6 |
=============== |
=============== |
7 |
|
|
8 |
|
[Note: The following are my notes for what should be written, |
9 |
|
not final text! --benja] |
10 |
|
|
11 |
|
The web: servers. {WebDAV}? Links break! Microcosm, alike; |
12 |
|
Xanadu, alike summat. (Tho no link breakage, given permanent ids.) |
13 |
|
[Read about Open Hypermedia work on permanent identifiers.] |
14 |
|
|
15 |
|
However, users do not live in a world of servers. |
16 |
|
Real-live data mobility. Server centricity not suited to this. |
17 |
|
It's well recognized that references should not be by location [ref URN]. |
18 |
|
|
19 |
|
(To explain data mobility: |
20 |
|
Data moves like this and that. The server/location paradigm |
21 |
|
is not suited to this: To support hypermedia functionality correctly, |
22 |
|
we need to recognize two copies of the *same* document.) |
23 |
|
|
24 |
|
Server centricity is what made the web scalable. Backlinks rejected |
25 |
|
for this reason [ref TBL]. However, recent innovations in P2P have made |
26 |
|
scalable hashtables possible. |
27 |
|
|
28 |
|
{If standards could be agreed on, web servers should be able to |
29 |
|
self-organize into a DHT implementing bidi links. There has been |
30 |
|
interest in p2p hypermedia [ref Bouvin]. This would not, however, |
31 |
|
solve data mobility on disconnected clients.}? |
32 |
|
|
33 |
|
A second issue arising from data mobility is version consolidation |
34 |
|
(as well as simply keeping track of alt. versions). [ref HTML |
35 |
|
version format proposal] Alternate versions important for |
36 |
|
authoring process [search refs]. (Note: Keeping track of versions |
37 |
|
structure is also \*hyper*media. Refs?) (WebDAV!) |
38 |
|
|
39 |
|
Ultimately, we need a system able to keep track of *all* |
40 |
|
alternative versions generated in the authoring process. |
41 |
|
(Even if distributed) |
42 |
|
|
43 |
|
Another challenging area of data mobility is the support for |
44 |
|
mobile and nomadic users [define]. Mobile users often have |
45 |
|
different machines, among which data must be Notes-replicated |
46 |
|
[ref Lotus Notes]. Also, caching of data for offline use. |
47 |
|
This also needs to be addressed for dialup users. Finally, |
48 |
|
train collaboration; this raises caching (local storage) |
49 |
|
as well as serverless versioning (like e-mail collaboration). |
50 |
|
|
51 |
|
We have raised a small set of issues that need to be addressed |
52 |
|
to support data mobility in hypermedia across a number of use cases: |
53 |
|
|
54 |
|
- [bulleted list] |
55 |
|
|
56 |
|
These use cases are not very visionary. |
57 |
|
All of these use cases except train collaboration are in use *today*. |
58 |
|
To support hypermedia functionality well in these cases, we need to |
59 |
|
address the issues above. |
60 |
|
|
61 |
|
We present a design which addresses the issues we have raised. |
62 |
|
We are currently in prototype stage, which we describe... |
63 |
|
|
64 |
|
This paper is structured as follows. |
65 |
|
|
66 |
|
|
67 |
2. Block storage |
2. Block storage |
68 |
================ |
================ |
69 |
|
|
88 |
7. Experience and future directions |
7. Experience and future directions |
89 |
=================================== |
=================================== |
90 |
|
|
91 |
|
Open issue: Tree hashing, also possibly needed for (OceanStore-like?) |
92 |
|
distribution of shares |
93 |
|
|
94 |
8. Conclusions |
8. Conclusions |
95 |
============== |
============== |
96 |
|
|