[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/01/24 09:57:16

Modified files:
        storm          : article.rst 

Log message:
        Notes on the introduction

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.33 manuscripts/storm/article.rst:1.34
--- manuscripts/storm/article.rst:1.33  Fri Jan 24 09:23:50 2003
+++ manuscripts/storm/article.rst       Fri Jan 24 09:57:16 2003
@@ -5,6 +5,65 @@
 1. Introduction
 ===============
 
+[Note: The following are my notes for what should be written,
+not final text! --benja]
+
+The web: servers. {WebDAV}? Links break! Microcosm, alike;
+Xanadu, alike summat. (Tho no link breakage, given permanent ids.)
+[Read about Open Hypermedia work on permanent identifiers.]
+
+However, users do not live in a world of servers.
+Real-live data mobility. Server centricity not suited to this.
+It's well recognized that references should not be by location [ref URN].
+
+(To explain data mobility:
+Data moves like this and that. The server/location paradigm
+is not suited to this: To support hypermedia functionality correctly,
+we need to recognize two copies of the *same* document.)
+
+Server centricity is what made the web scalable. Backlinks rejected
+for this reason [ref TBL]. However, recent innovations in P2P have made
+scalable hashtables possible.
+
+{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]. 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
+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
+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]
+
+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.
+
+We present a design which addresses the issues we have raised.
+We are currently in prototype stage, which we describe...
+
+This paper is structured as follows.
+
+
 2. Block storage
 ================
 
@@ -28,6 +87,9 @@
 
 7. Experience and future directions
 ===================================
+
+Open issue: Tree hashing, also possibly needed for (OceanStore-like?)
+distribution of shares
 
 8. Conclusions
 ==============