45 |
published on the web, moved between desktop and laptop systems, |
published on the web, moved between desktop and laptop systems, |
46 |
downloaded for off-line reading or copied between computers in a LAN. |
downloaded for off-line reading or copied between computers in a LAN. |
47 |
Furthermore, the same document is independently modified |
Furthermore, the same document is independently modified |
48 |
on two (or more) unconnected, separete systems. We address two issues |
on two (or more) unconnected, separete systems. We use |
49 |
raised by this ad hoc *data mobility* (see footnote) phenomenon: Dangling links, |
*data mobility* as a collective term for the movement of documents |
50 |
and keeping track of alternative versions. Resolvable location independent identifiers |
between computers (or locations on one computer, such as folders), |
51 |
|
and movement of content between documents (through copy&paste) [#]_. |
52 |
|
|
53 |
|
.. [#] While the physical mobility of e.g. notebooks may introduce |
54 |
|
data mobility (for example due to caching for off-line access), |
55 |
|
XXX |
56 |
|
|
57 |
|
We address two issues raised by data mobility: |
58 |
|
Dangling links and keeping track of alternative versions. |
59 |
|
Resolvable location independent identifiers |
60 |
make these issues much easier to deal with, since data |
make these issues much easier to deal with, since data |
61 |
can be recognized whereever it is moved. The design also allows for |
can be recognized whereever it is moved. {{The design also allows for |
62 |
automatic balancing of the load, which occurs in location-dependent |
automatic balancing of the load, which occurs in location-dependent |
63 |
situations with popular items. |
situations with popular items.}} |
|
|
|
|
footnote: we emphasize the mobility of *data*. Indeed, technology used |
|
|
for transferring data is not our primary concern. On the other hand, the |
|
|
mobility of people is obviously a particular reason for data mobility. |
|
|
For data mobility, the mobility of people shows as the mobility of the |
|
|
data processing devices, between/among which the data is shared |
|
|
(transferred). XXX Hence, solving issues of data mobility may address e.g. |
|
|
problems of mobile hypermedia. |
|
64 |
|
|
65 |
In this paper, we present Storm (for *storage module*), a design |
In this paper, we present Storm (for *storage module*), a design |
66 |
for dealing with these issues. Storm provides an interface to |
dealing with these issues. Storm is a library |
67 |
applications for storing and retrieving data in immutable |
for storing and retrieving data in immutable |
68 |
byte sequences identified by cryptographic content hashes |
byte sequences identified by cryptographic content hashes |
69 |
[ref ht'02 paper], unifying the namespaces of |
[ref ht'02 paper], unifying the namespaces of |
70 |
private data and documents published on the Internet by |
private data and documents published on the Internet by |
71 |
using the same identifiers for both. |
using the same identifiers for both. Storm provides services |
72 |
|
for storing versioned data and Xanalogical storage [ref]. |
73 |
|
The Storm design, a hypermedia system built to make use |
74 |
The main contributions of this paper are |
of the emerging peer-to-peer search technologies, |
75 |
-Storm - design which employs new techniques for hypermedia |
is the main contribution of this paper. |
|
systems (location independent identifiers, immutable block storage, *working* links etc.) |
|
|
-use of p2p architecture in hypermedia domain |
|
76 |
|
|
77 |
Currently, Storm has been partially implemented as a part of the Gzz |
Currently, Storm is partially implemented as a part of the Gzz |
78 |
project [ref], which uses Storm exclusively for all disk storage. |
project [ref], which uses Storm exclusively for all disk storage. |
79 |
Gzz provides a general platform for building hypermedia applications upon. |
Gzz provides a general platform for building hypermedia applications upon. |
80 |
On top of Storm, we have built a system for storing mutable, versioned data |
On top of Storm, we have built a system for storing mutable, versioned data |
88 |
of our implementation of Xanalogical storage is to be taken. |
of our implementation of Xanalogical storage is to be taken. |
89 |
(Vitali [ref] notes that Xanalogical storage necessiates |
(Vitali [ref] notes that Xanalogical storage necessiates |
90 |
strong discipline in version tracking, which current systems lack.) |
strong discipline in version tracking, which current systems lack.) |
91 |
Investigating the degrees of interoperability with (other) Open Hypermedia |
Investigating the degrees of interoperability with Open Hypermedia |
92 |
(/Structural Computing?) and (more primitive?) other (Web) XXX is a possible |
(/Structural Computing?) and (more primitive?) other (Web) XXX is a possible |
93 |
direction for future work, and will be preliminarly discussed here too. |
direction for future work, and will be preliminarly discussed here too. |
94 |
|
[benja says: Really? Do we/can we discuss that really?] |
95 |
|
|
96 |
This paper is structured as follows. In next section, we describe |
This paper is structured as follows. In next section, we describe |
97 |
related work. In section 3, we introduce the basic storage unit of our |
related work. In section 3, we introduce the basic storage unit of our |
109 |
currently split in two - hinting somewhere in the beginning and reviewing at |
currently split in two - hinting somewhere in the beginning and reviewing at |
110 |
the and). |
the and). |
111 |
[In appendix A ? -Hermanni] |
[In appendix A ? -Hermanni] |
112 |
|
[IMHO: Use cases in intro, discussion on how Storm applies to them |
113 |
|
to the end/in Conclusions. -b] |
114 |
|
|
115 |
|
|
116 |
2. Related Work |
2. Related Work |