gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz-commits] manuscripts/storm article.rst


From: Hermanni Hyytiälä
Subject: [Gzz-commits] manuscripts/storm article.rst
Date: Mon, 20 Jan 2003 09:52:19 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Hermanni Hyytiälä <address@hidden>      03/01/20 09:52:18

Modified files:
        storm          : article.rst 

Log message:
        antont's merge by hemppah

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.21 manuscripts/storm/article.rst:1.22
--- manuscripts/storm/article.rst:1.21  Mon Jan 20 08:21:30 2003
+++ manuscripts/storm/article.rst       Mon Jan 20 09:52:17 2003
@@ -22,8 +22,7 @@
 [cerf:internetplantary_internet]. This sets challenges for the "freedom"
 (referring to 1.) of data movement, as there are limits to the reach and
 performance of the networks (incl-from:antont->ohs-talk/disconnected?).
-Problems include disconnections (due to e.g. breakages), ..
-OTOH: server downtimes etc.
+Problems include disconnections (due to e.g. breakages), ...
 
 Thirdly, the amount of internetworked computers will increase rapidly, as
 new kinds of devices are being connected via different channels to the
@@ -130,7 +129,7 @@
 e.g. Nokia Communicator calendar data into/from Lotus Notes calendar --> 'used 
between different systems'.
 
 
--Worth to mention is that Ray Ozzie is a man behind Lotus Notes and Groove; 
Lotus Notes
+hemppah: worth to mention is that Ray Ozzie is a man behind Lotus Notes and 
Groove; Lotus Notes
 is based on client-server model and, Groove is based on p2p model --> possible 
direction etc. ? 
 
 
@@ -154,6 +153,84 @@
 
 Thus we have four goals which we must express in the article.
 
+...
+
+so: if there is a permanent network connection, are there reasons for
+using this? (i.e. being out of sync in the first place)
+
+one argument is that there is no such thing as "permanent connection" (in
+a way e.g. a hard disk failure can be thought of as a connection breakdown
+to the data on the drive ?)
+
+but of course synchronization might be the way to approach it, just that
+the irregularity is/may_be caused by the, well, intermittent connectivity?
+
+should the goals be derived from the use cases? or perhaps better looked in
+their light ("niiden valossa") -- take the case of e-mail attachments:
+
+Think of a use case here: email attachments. Between two computers that 
+are permanently on the 'net, you *could* replace email attachments by 
+"simply" setting up a shared file system between the sender and the 
+receiver of the attachment. Then, if the receiver made a modification, 
+the sender could even see it immediately. Yet nobody seems to be 
+proposing this. The overhead is one thing. Why 
+set up and maintain a shared file system for every file you send to 
+somebody? Privacy is another. You don't want the sender being able to 
+keep track what the receiver does with the document.
+
+... but don't some senders want to be able to track what the receivers do?
+(and thinking of the web: how do you get a "weblog" of a p2p published data?)
+
+And if you don't set up such a file system, but just send an email 
+attachment, you've got intermittent synchronization between two 
+permanently connected computers.
+
+Another question is, should e-mail attachments be used to share data.
+
+It may be natural when you want one specific person  (or small group of 
people) to look at a document.
+...
+> rsync is an intermittent synchronization solution :-) (it's not about
+> shared file systems, but synchronizing two copies of a file system   
+> intermittently).
+
+from:erno
+"firewalls" should be in end systems. ipsec was originally meant to
+be run in transport mode and provide end to end security, to
+work nicely with the ip philosophy.
+| >  > i prefer URI:s.
+| i.e. with today's technology, i prefer to put documents on the web or some
+| (other) filesystem within the recipients' reach.
+aren't these two orthogonal? in one case you get a copy of the
+document, in another case you get a (weak) reference to the document.
+i like the "disconnected operation" and loose caching semantics.
+another thing about filesystems, it's not a very precise concept...
+there are several components/aspects.
+(replace "is" with "can be" according to taste:)
+ * it's a namespace
+ * it's a wire protocol for conducting operations on an object
+ * it's an access control system
+ * it's a way for people to collaborate
+ * it's a locking protocol
+ * it's a tracking facility (access_log)
+  ....
+> but i still want to have the option of really making sure
+> i have a local copy of a document sitting on my disk, instead
+> of in a local cache that will be flushed before long.
+sure. and i want to have an option, that if any of the four-five machines
+at the studio suffer data loss, work would not be lost, but there's
+backups (also for situations when a machine is off-line etc.), within the
+limited resources of course.
+>   -- erno
+~Toni
+> what will people do when they have 3200GB disks and realise
+> they only have useful date to fill 10% of that but would
+> like more reliability?
+OTOH: already in the "grey economy" shares of increasing size are required
+to participate in the network, i.e. you get the movies you want if you
+provide lots of what other's need. and if you don't have any, you're out.
+but this is something gzz want's to avoid, too.
+
+
 
 References:
 
@@ -180,8 +257,23 @@
 - Freenet, Free Haven et al
 - The pointer problem: CFS, OceanStore
 - A commercial p2p-based collaboration tool: Groove 
(http://erwin.dstc.edu.au/Herring/GrooveAnalysis-SCI2001.pdf)
-- Potential hypermedia implementation with non-breaking links: Microcosm
-- Squirrel: a decentralized peer-to-peer we cache
+- Hypermedia implementations with non-breaking links: Microcosm, Hyper-G
+- Open Hypermedia, data and link servers? (links not in documents!)
+       * term in the hypermedia engineering -book: link management
+- (but not structural computing. hypertext functionality? not really.)
+- Persistent storage: the first 13years (dig bookmark from tolp42:galeon)
+- primitive sync stuff: rsync (ssync?), SyncML?
+- about ibm corporate p2p over http:
+ http://www.almaden.ibm.com/cs/people/bayardo/userv/
+ http://www.almaden.ibm.com/cs/people/bayardo/userv/userv.html
+
+is this relevant:  P. Druschel and A. Rowstron. PAST: A largescale,
+persistent peer-to-peer storage utility. In IEEE, editor, Eighth IEEE
+Workshop on Hot Topics in Operating Systems (HotOS-VIII). May 20-23, 2001,
+Schloss Elmau, Germany, pages 75-80, 1109 Spring Street, Suite 300, Silver
+Spring, MD 20910, USA, 2001. IEEE Computer Society Press. ?
+
+- Squirrel: a decentralized peer-to-peer web cache
 - Feasibility of a Serverless Distributed File System Deployed on an Existing 
Set of Desktop PCs
 - Distributed File Systems: Concepts and Example ('de facto article on DFS')
 - Lotus Notes: 
ftp://ftp.lotus.com/pub/lotusweb/product/notes/G325-2061-00_j.pdf
@@ -194,4 +286,3 @@
 
 Comments on references:
 - Yes, PAST is relevant. It's very similar to CFS (and Oceanstore)
-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]