/[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.107 by antont, Fri Feb 7 06:11:45 2003 UTC revision 1.108 by benja, Fri Feb 7 15:09:27 2003 UTC
# Line 126  usable yet. Line 126  usable yet.
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
# Line 197  workarounds from the p2p solution's poin Line 197  workarounds from the p2p solution's poin
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
# Line 235  Related work: we need something about p2 Line 232  Related work: we need something about p2
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  ================  ================

Legend:
Removed from v.1.107  
changed lines
  Added in v.1.108

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