126 |
.. [General figure of Storm, i.e. application layer, storm layer, |
.. [General figure of Storm, i.e. application layer, storm layer, |
127 |
netowork layer ? -Hermanni] |
netowork layer ? -Hermanni] |
128 |
|
|
129 |
.. [Move somewhere else -b]:: |
.. [Move somewhere else -b]: |
130 |
[Section 8 ?-) -Hermanni] |
[Section 8 ?-) -Hermanni] |
131 |
No work on integrating Storm with current programs (in the spirit of Open Hypermedia) |
No work on integrating Storm with current programs (in the spirit of Open Hypermedia) |
132 |
has been done so far. It is not clear how far this is possible |
has been done so far. It is not clear how far this is possible |
197 |
-- agreed: we're talking server-centric vs documents-not-bound-to-server, |
-- agreed: we're talking server-centric vs documents-not-bound-to-server, |
198 |
here; I believe most distributed hymedia sys are server-centric in this sense.] |
here; I believe most distributed hymedia sys are server-centric in this sense.] |
199 |
|
|
|
.. [#] Except if the new server is a complete replacement for the old, |
|
|
inheriting the Internet domain. |
|
|
|
|
200 |
Likewise, version control systems like CVS or RCS [ref] usually assume |
Likewise, version control systems like CVS or RCS [ref] usually assume |
201 |
a central server hosting a repository. The WebDAV/DeltaV protocols, |
a central server hosting a repository. The WebDAV/DeltaV protocols, |
202 |
designed for interoperability between version control systems, inherit |
designed for interoperability between version control systems, inherit |
232 |
|
|
233 |
It's well recognized that references should not be by location [ref URN]. |
It's well recognized that references should not be by location [ref URN]. |
234 |
|
|
235 |
{If standards could be agreed on, web servers should be able to |
[ref HTML version format proposal] Alternate versions important for |
|
self-organize into a DHT implementing bidi links. There has been |
|
|
interest in p2p hypermedia [ref Bouvin, Wiil ("Peer-to-Peer Hypertext")]. |
|
|
This would not, however, solve data mobility on disconnected clients.}? |
|
|
|
|
|
A second issue arising from data mobility is version consolidation |
|
|
(as well as simply keeping track of alt. versions). [ref HTML |
|
|
version format proposal] Alternate versions important for |
|
236 |
authoring process [search refs]. (Note: Keeping track of versions |
authoring process [search refs]. (Note: Keeping track of versions |
237 |
structure is also \*hyper*media. Refs?) (WebDAV!) |
structure is also \*hyper*media. Refs?) (WebDAV!) |
238 |
|
|
239 |
Ultimately, we need a system able to keep track of *all* |
Nomadicity [ref]. Mobile users often have |
|
alternative versions generated in the authoring process. |
|
|
(Even if distributed) |
|
|
|
|
|
Another challenging area of data mobility is the support for |
|
|
mobile and nomadic users [define]. Mobile users often have |
|
240 |
different machines, among which data must be Notes-replicated |
different machines, among which data must be Notes-replicated |
241 |
[ref Lotus Notes]. Also, caching of data for offline use. |
[ref Lotus Notes]. Also, caching of data for offline use. |
242 |
This also needs to be addressed for dialup users. Finally, |
This also needs to be addressed for dialup users. Finally, |
243 |
train collaboration; this raises caching (local storage) |
train collaboration; this raises caching (local storage) |
244 |
as well as serverless versioning (like e-mail collaboration). |
as well as serverless versioning (like e-mail collaboration). |
245 |
|
|
|
We have raised a small set of issues that need to be addressed |
|
|
to support data mobility in hypermedia across a number of use cases: |
|
|
|
|
|
- [bulleted list] |
|
|
|
|
|
1. Mr. A and Mrs. B meet live, say in a cafe or on a train, to collaborate |
|
|
by using laptops. They open their computers that are equipped with wireless |
|
|
connectivity (e.g. WLAN/WiFi or Bluetooth) and appropriate network drivers, |
|
|
so that an ad-hoc network emerges automatically as the machines discover |
|
|
each-other (by using e.g. the IETF Zeroconf protocol for IP configuration). |
|
|
Via Storm they can see the data the other is sharing, along with their own |
|
|
as well as the external documents they have with them. Before leaving, hence |
|
|
disconnecting, they can choose the documents to take with them (i.e. copy). |
|
|
|
|
|
2. A and B work separately on the same document, so that there are now two |
|
|
different versions of it -- let's call them them versions 1.1a and 1.1b. |
|
|
Then they contact each other via e.g. e-mail, sending their new documents as |
|
|
attachments. |
|
|
|
|
|
3. B publishes the document on the Internet, hosting on her laptop only. |
|
|
|
|
|
4. A and some other people view and comment the document with their |
|
|
machines, also bookmarking it and linking from their own pages (e.g. blogs). |
|
|
|
|
|
5. B travels with the laptop, taking it off-line. |
|
|
|
|
|
6. Increasingly many people continue to look at the document. |
|
|
|
|
|
7. B arrives at a friend of hers, reconnects the laptop. |
|
|
|
|
|
.. |
|
|
|
|
|
These use cases are not very visionary. |
|
|
All of these use cases except train collaboration are in use *today*. |
|
|
To support hypermedia functionality well in these cases, we need to |
|
|
address the issues above. |
|
|
|
|
246 |
|
|
247 |
3. Block storage |
3. Block storage |
248 |
================ |
================ |