[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/07 10:09:27

Modified files:
        storm          : article.rst 

Log message:
        remove stuff from Related Work section that doesn't belong there and/or
        has already been addressed

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/storm/article.rst.diff?tr1=1.107&tr2=1.108&r1=text&r2=text

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.107 manuscripts/storm/article.rst:1.108
--- manuscripts/storm/article.rst:1.107 Fri Feb  7 01:11:45 2003
+++ manuscripts/storm/article.rst       Fri Feb  7 10:09:27 2003
@@ -126,7 +126,7 @@
 .. [General figure of Storm, i.e. application layer, storm layer, 
    netowork layer ? -Hermanni]
  
-.. [Move somewhere else -b]::
+.. [Move somewhere else -b]:
    [Section 8 ?-) -Hermanni]
    No work on integrating Storm with current programs (in the spirit of Open 
Hypermedia)
    has been done so far. It is not clear how far this is possible
@@ -197,9 +197,6 @@
 -- agreed: we're talking server-centric vs documents-not-bound-to-server,
 here; I believe most distributed hymedia sys are server-centric in this sense.]
 
-.. [#] Except if the new server is a complete replacement for the old,
-   inheriting the Internet domain.
-
 Likewise, version control systems like CVS or RCS [ref] usually assume
 a central server hosting a repository. The WebDAV/DeltaV protocols,
 designed for interoperability between version control systems, inherit
@@ -235,65 +232,16 @@
 
 It's well recognized that references should not be by location [ref URN].
 
-{If standards could be agreed on, web servers should be able to
-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
+[ref HTML version format proposal] Alternate versions important for
 authoring process [search refs]. (Note: Keeping track of versions
 structure is also \*hyper*media. Refs?) (WebDAV!)
 
-Ultimately, we need a system able to keep track of *all*
-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
+Nomadicity [ref]. Mobile users often have
 different machines, among which data must be Notes-replicated
 [ref Lotus Notes]. Also, caching of data for offline use.
 This also needs to be addressed for dialup users. Finally,
 train collaboration; this raises caching (local storage)
 as well as serverless versioning (like e-mail collaboration).
-
-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.
 
 
 3. Block storage