/[gzz]/manuscripts/storm/SCRATCH
ViewVC logotype

Diff of /manuscripts/storm/SCRATCH

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.2 by antont-oulu_fi, Tue Jan 21 10:09:43 2003 UTC revision 1.3 by benja, Fri Jan 24 14:23:50 2003 UTC
# Line 1  Line 1 
1    
2    Many hypermedia systems place each document and link in the custody
3    of one server, rendering it unusable when connectivity fails.
4    For example, on the web, when connection to a server fails,
5    links to documents on this server can generally not be followed.
6    Open Hypermedia Systems such as Microcosm [ref] store links
7    in *linkbases* on specific servers. In the Xanadu 88.1 design [ref],
8    documents and links can be cached, but still have a 'home' server
9    on which a 'master' copy is located. [XXX look more into it, correct xu terms]
10    
11    Such a system does not lend itself well to a world
12    where servers fail, where clients are not 'always on,' and
13    where documents regularly move from computer to computer in the form
14    of email attachments. In a system where documents and links
15    belong to one server, in a disconnected state documents
16    cannot be retrieved and links cannot be followed.
17    [XXX this isn't precise-- it's not true in this form]
18    When documents are forwarded per email or downloaded from the Web today,
19    links generally break.
20    
21    We propose a system implementing Xanalogical storage [ref Ted]
22    based on global, location-independent identifiers, where
23    document contents are named by cryptographical hashes [ref GUID paper].
24    Assuming an index of all documents and links
25    on the local computer and all systems that can be reached through
26    the currently available network connections. Since no centralized
27    scheme can scale to such an index of "everything," keeping one
28    for the public Internet requires a decentralized,
29    self-organizing distributed system (the IPTPS'03 definition
30    of "peer-to-peer" [ref]).
31    
32    We propose to use this same system for publication on the 'net
33    and storage on a local computer. This means that
34    when a local document is published or a public document
35    is saved locally, it retains its identifier; as long as a
36    document is also accessible through the network, keeping
37    a local copy is merely an efficiency measure (keeping
38    a permanent cache). Obviously, in such scheme, as long as link
39    remains accessible, it never breaks just because the documents
40    it refers to are moved to a different location.
41    
42    The Squirrel system [ref] is a peer-to-peer network of shared
43    browser caches, where a web page can be retrieved from
44    any computer in a local network that has a copy in its cache.
45    Our distributed index for document and link retrieval would
46    have this as a natural side-effect, except
47    that it would also extend any data that has been permanently
48    downloaded on one of the network's computers.
49    
50    A system as we propose would necessiate deep changes in applications.
51    As Vitali [ref Versioning hypermedia] notes, any implementation
52    of Xanalogical storage necessiates this, as "[n]o approximate,
53    good-enough solutions" for the management of global identifiers
54    "can conceivably be considered acceptable in this case." [#]_
55    As such, we are cannot meet the minimum definition of an
56    open hypermedia system, as given by Davis et al [ref]:
57    We do impose storage of markup on applications and we cannot
58    generally use data created by tools that are not aware of our system.
59    
60    ...
61    
62    
63    
64    .. [#] We have built a system for editing Xanalogical text
65       in a non-aware editor such as ``emacs``, attempting to
66       determine the user's changes through structure matching [ref].
67       This seems to work reasonably well for insertions,
68       removals and rearrangements, but is hopeless if the user
69       uses copy&paste between arbitrary documents.
70    
71    
72    
73    
74    
75    
76    
77    Stuff not yet located in the article :-)
78    ========================================
79    
80    (remove-at-will: There are two kinds of mobility related to hypermedia use:)
81    
82    In today's networked world, data moves freely between computers:
83    Text is copied from one document to another, documents
84    are moved between folders,
85    copied from one computer to another, sent by email,
86    independently modified on two computers simultaneously,
87    published on a server, moved to a different server, downloaded
88    by a client. Yet, every time content is moved, links and references to it break
89    in popular hypermedia systems.
90    
91    Also, computers are used by people who are increasingly mobile
92    [psych mobility research -paper], on global range.
93    There are even prospects of interplanetary use of digital communications
94    [cerf:internetplantary_internet]. This sets challenges for the "freedom"
95    (referring to 1.) of data movement, as there are limits to the reach and
96    performance of the networks (incl-from:antont->ohs-talk/disconnected?).
97    Problems include disconnections (due to e.g. breakages), ...
98    
99    Thirdly, the amount of internetworked computers will increase rapidly, as
100    new kinds of devices are being connected via different channels to the
101    unifying Internet, creating heavy masses of usage. When pieces of content
102    are tied to a location, a lot of traffick (tiivistyy) near a single point
103    of
104    failure. Therefore the common URL addressing on the Web may fail ...
105    OTOH, yet: server downtimes etc.
106    
107    Research has been done in a number of areas to alleviate this problem.
108    There are a number of proposals for sharing a web browser's cache
109    between users [squirrel].
110    ...
111    Thompton and De Roure [ref ht'01] propose a peer-to-peer system
112    for discovering cached web resources in a mobile, disconnected setting,
113    available on the client or other systems connected to it through
114    ad-hoc local networks (e.g., wireless).
115    
116    ...
117    
118    We aim for a solution that will support mobility for all of a user's data
119    (everything they'd store in their personal directory). Any pieces of text,
120    any document and any collection of documents should be easy to move
121    to a different computer, and after modifying the data on both systems,
122    it should be easy to bring the two copies back in sync.
123    
124    Another motivation (right?) for the data sharing / data mobility is
125    collaboration. Within an organization or a project group, there often is a
126    shared file system, e.g. a file server in the local network, so that
127    different people do not need their personal copies of the data but can work
128    (synchronously) on the same items. Often, however, especially when
129    crossing organizationary boundaries there is no access each-others'
130    filesystems even though data is shared. In actual collaboration, where
131    several individuals work on the same items -- possibly at the sametime --
132    the data effectually forks. So similarly(?) to the the situation where a
133    particular user has data on different computers, data needs to be kept in
134    sync when there is collaboration. [cvs, (perforce, ..)]
135    
136    Our system allows documents and document content to be freely copied
137    without breaking links. As long as a link and the documents
138    it links are currently accessible, the link can be shown.
139    We archieve this by assigning documents and contents permanent,
140    location-independent identifiers, and keeping an efficient (hemppah: should
141    we emphasize a *distributed* index ?) index of all data by its identity.
142    
143    ----
144    
145    This type of system does not lend itself well to a world
146    where servers fail and clients are not permanently 'on.'
147    Hypermedia functionality ought to be a service at the
148    operating system level, usable for organizing all data
149    a user stores on their system [ref]. It is of course possible
150    for a user to run an own, personal linkbase on their client system,
151    
152    In an ideal world, when users move documents between computers,
153    links would not break, ...,
154    different versions of documents could easily be reconciled,
155    (file structure would not be lost). We envision a global identifier space,
156    where links are created between global identifiers, and whenever
157    any two endpoints of a link are known, this link can be shown.
158    
159    
160    
161    
162    
163    
164    Xanalogical storage
165    ===================
166    
167    In the xanalogical storage model [cite], pioneered by Project Xanadu [cite],
168    links are not between documents, but individual characters.
169    When a character is first typed in, it acquires a permanent ID
170    ("the character 'D' typed by Janne Kujala on 10/8/97 8:37:18"),
171    which it retains when copied to a different document, distinguishing
172    it from all similar characters typed in independently.
173    A link is shown between any two documents containing the characters
174    that the link connects. Xanalogical links are external and bidirectional.
175    
176    In addition to content links, xanalogical storage keeps an index of
177    transclusions: identical characters copied into different documents.
178    Through this mechanism, the system can show to the user all documents
179    that share text with the current document.
180    
181    
182    
183    
184    
185    Idea/Plan
186    =========
187    
188    [Notes for the authors, not part of the final document
189    though text may be moved from here to there.]
190    
191    Whenever a document moves on the current web, links to it break,
192    be it from an author's computer to a public server,
193    from one server to another, from the server to a client,
194    or from one personal computer to another. We subsume
195    these forms of movement under the term 'data mobility.'
196    
197    
198    Storm goals/benefits:
199    
200    - Reliability
201      - Append-and-delete-only
202      - The same data can be stored in many locations,
203        allowing it to be easily reconstructed after failure
204      - Versioning: Old versions remain accessible
205    - Xanalogical storage
206    - If a document is accessible, references to it work
207    - Links do not break
208    - Easy syncing:
209      - Just copy a bunch of blocks
210      - Documents can be synced & merged
211      - Inter-document structures can be synced & merged
212      - Syncing can be done without merging immediately,
213        leaving two alternative versions current
214        (so e.g. an automated process is entirely possible,
215        even when there are conflicts)
216    - Versioning
217    
218    
219    Grouped differently,
220    
221    - Reliability (as above)
222    - Usablility in the face of intermittent connectivity
223      (includes syncing, finding a document if available...)
224    - Xanalogical structure
225      (includes versioning, non-breaking links etc.)
226    
227    Storm limitations/weaknesses:
228    
229    - what, actually?
230    
231    antont ponders: for files storm is ok, but how about:
232    - irc? (latency?)
233    - video? (throughput)
234    
235    and:
236    .. multipoint live video? (both latency and throughput demands)
237    
238    * does it make sense to think of irc messages, and/or video frames, as
239    datablocks .. or what?
240    
241      
242    hemppah's comment on syncing term:
243    I'd prefer term 'replication' instead of term syncing, when
244    updating data to 'the most recent state'. E.g. Lotus Notes uses
245    term replication, when one performs locally made updates into
246    a centralized server --> 'used within same system'. Syncing term, however,
247    is used when importing/exporting e.g. Nokia Communicator calendar data into/from
248    Lotus Notes calendar --> 'used between different systems'.
249    
250    
251    hemppah: worth to mention is that Ray Ozzie is a man behind Lotus Notes and Groove;
252    Lotus Notes is based on client-server model and, Groove is based on p2p model -->
253    possible direction etc. ?
254    
255    hemppah: I think we should mention that in Gzz one refer to data in non-hierarchial
256    way, where as in Notes (and other systems also, references!!), we must use
257    hierarchial way. In Notes most important IDs are:
258    1) every document has a unique identifier, which is unique among all replicas
259    of database
260    2) every document/design element has a identifier, named as noteID, which is unique
261    in database, but not among all replicas of database
262    3) every view has a unique identifier,  which is unique among all replicas of
263    database
264    4) every database has a replica ID, which identifies database's replicas
265    among all databases
266    
267    So, if we want to refer to a document, we use format:
268    
269    replicaID/viewID/documentID
270    
271    Also, we can refer to same document, through *many different* views (analogical to Gzz's dimensions ?):
272    notes://<server>/replicaID/viewID1/documentID
273    notes://<server>/replicaID/viewID2/documentID
274    
275    Here's a real example:
276    Notes://server/D235632D00313587/38D22BF5E8F088348525JK7500129B2C/REWB3FDE0D53807B67C2256CB50026FCVV
277    
278    For information about IDs in Notes:
279    http://www-12.lotus.com/ldd/doc/tools/c/4.5/api45ug.nsf/85255d56004d2bfd85255b1800631684/00d000c1005800c985255e0e00726863?OpenDocument
280    
281    In Gzz, however, we don't know the location, we know only the *identity* of data what we are looking for, as follows:
282    
283    urn-5:FAB3FDE0hgfD5kkjj3807B67C2256CfsdB50026FC51
284    
285    Above is not a *correct* urn-5, but very similar to last part of notes' syntax.
286    
287    <<<<<<< article.rst
288    benja's reply:
289    Hm. Replication to me means, the same data is kept on multiple
290    machines. This is not what we are talking about here: We're talking
291    about *different versions* of the same data being kept
292    on multiple machines, and occasionally being 'brought into sync'
293    with each other. If I send you a draft article and you comment on it,
294    and I make changes too, and later I merge the two divergent
295    versions back together, 'syncing' seems approximately right,
296    but 'replication' seems completely wrong to me.
297    
298    =======
299    (Of course, this is very similar to 'normal' URLs, but our purpose here is to give an example
300    of how one refer to a particular data item in colloboration-like tool, like Notes)
301    >>>>>>> 1.28
302    
303    In Notes, there are servers, which maintain replication of data, opposite to Gzz. What is
304    interesting in Notes' replication, is the fact that the replication of database not only
305    replicate the *data* but also design of data, which represent the data.
306    Worth to mention is also that, even if the data and the design of data (logic etc.) is
307    in the *same* (physical) structure, data and design of data is very loosely coupled with
308    each other.
309    
310    Additionally, we should emphatize that how things are going towards non-hierarchical reference models,
311    for instance, Notes(hierarchical) and Gzz(non-hierarchical), which both are based on the same
312    xanalogical model.
313    
314    "Usability in the face of intermittent connectivity" is
315    more than just mobile applications: It is also copying data
316    from one computer to another, where the two computers'
317    file systems are not kept in sync through a permanent
318    network connection. Hmm, maybe "Usability in the face
319    of irregular synchronization" or some such would
320    make it clearer?
321    
322    Ok, let's split that in two:
323    
324    - Usability in the face of intermittent connectivity
325      (we cannot access data stored on the internet)
326    - Usability in the face of non-synchronization
327      (we can have two independent versions of something
328      on two unconnected computers and we can easily
329      synchronize the two versions when desired)
330      
331    
332    Thus we have four goals which we must express in the article.
333    
334    ...
335    
336    so: if there is a permanent network connection, are there reasons for
337    using this? (i.e. being out of sync in the first place)
338    
339    one argument is that there is no such thing as "permanent connection" (in
340    a way e.g. a hard disk failure can be thought of as a connection breakdown
341    to the data on the drive ?)
342    
343    but of course synchronization might be the way to approach it, just that
344    the irregularity is/may_be caused by the, well, intermittent connectivity?
345    
346    should the goals be derived from the use cases? or perhaps better looked in
347    their light ("niiden valossa") -- take the case of e-mail attachments:
348    
349    Think of a use case here: email attachments. Between two computers that
350    are permanently on the 'net, you *could* replace email attachments by
351    "simply" setting up a shared file system between the sender and the
352    receiver of the attachment. Then, if the receiver made a modification,
353    the sender could even see it immediately. Yet nobody seems to be
354    proposing this. The overhead is one thing. Why
355    set up and maintain a shared file system for every file you send to
356    somebody? Privacy is another. You don't want the sender being able to
357    keep track what the receiver does with the document.
358    
359    ... but don't some senders want to be able to track what the receivers do?
360    (and thinking of the web: how do you get a "weblog" of a p2p published data?)
361    
362    And if you don't set up such a file system, but just send an email
363    attachment, you've got intermittent synchronization between two
364    permanently connected computers.
365    
366    Another question is, should e-mail attachments be used to share data.
367    
368    It may be natural when you want one specific person  (or small group of people) to look at a document.
369    ...
370    > rsync is an intermittent synchronization solution :-) (it's not about
371    > shared file systems, but synchronizing two copies of a file system  
372    > intermittently).
373    
374    from:erno
375    "firewalls" should be in end systems. ipsec was originally meant to
376    be run in transport mode and provide end to end security, to
377    work nicely with the ip philosophy.
378    | >  > i prefer URI:s.
379    | i.e. with today's technology, i prefer to put documents on the web or some
380    | (other) filesystem within the recipients' reach.
381    aren't these two orthogonal? in one case you get a copy of the
382    document, in another case you get a (weak) reference to the document.
383    i like the "disconnected operation" and loose caching semantics.
384    another thing about filesystems, it's not a very precise concept...
385    there are several components/aspects.
386    (replace "is" with "can be" according to taste:)
387     * it's a namespace
388     * it's a wire protocol for conducting operations on an object
389     * it's an access control system
390     * it's a way for people to collaborate
391     * it's a locking protocol
392     * it's a tracking facility (access_log)
393      ....
394    > but i still want to have the option of really making sure
395    > i have a local copy of a document sitting on my disk, instead
396    > of in a local cache that will be flushed before long.
397    sure. and i want to have an option, that if any of the four-five machines
398    at the studio suffer data loss, work would not be lost, but there's
399    backups (also for situations when a machine is off-line etc.), within the
400    limited resources of course.
401    >   -- erno
402    ~Toni
403    > what will people do when they have 3200GB disks and realise
404    > they only have useful date to fill 10% of that but would
405    > like more reliability?
406    OTOH: already in the "grey economy" shares of increasing size are required
407    to participate in the network, i.e. you get the movies you want if you
408    provide lots of what other's need. and if you don't have any, you're out.
409    but this is something gzz want's to avoid, too.
410    
411    
412    
413    References:
414    
415    - CFS (The Chord project's Cooperative File System)
416    - Coda ("an advanced network filesystem", http://www.coda.cs.cmu.edu/)
417    - The Internet Backplane Protocol
418    - Issue about nomadicity, Communications of the ACM (Sep 2001)
419      - Note: Support for nomadicity includes scaling of resource
420        usage (e.g. bandwidth availability), which we're
421        less concerned with here.
422      - Future work needed: Currently, the Storm interfaces
423        do not provide information about underlying network conditions,
424        thus we can't e.g. show to the user what blocks
425        are available w/o network lookup and which aren't.
426    - Delay-tolerant networks (http://dtnsig.org/)
427    - OceanStore
428    - Lifestreams, because they are a project believing
429      that the network [probably, a server] should hold
430      the users' data, not the terminal they access it through
431      - Possible reference here: IMAP?
432    - The IPTPS'03 call for papers' definition of peer-to-peer
433    - P2P Working group: definition of peer-to-peer
434    - Hypermedia by coincidence, Thompton et al (HT'01)
435    - Freenet, Free Haven et al
436    - The pointer problem: CFS, OceanStore
437    - A commercial p2p-based collaboration tool: Groove (http://erwin.dstc.edu.au/Herring/GrooveAnalysis-SCI2001.pdf)
438    - Hypermedia implementations with non-breaking links: Microcosm, Hyper-G
439    - Open Hypermedia, data and link servers? (links not in documents!)
440            * term in the hypermedia engineering -book: link management
441    - (but not structural computing. hypertext functionality? not really.)
442    - Persistent storage: the first 13years (dig bookmark from tolp42:galeon)
443    - primitive sync stuff: rsync (ssync?), SyncML?
444    - about ibm corporate p2p over http:
445     http://www.almaden.ibm.com/cs/people/bayardo/userv/
446     http://www.almaden.ibm.com/cs/people/bayardo/userv/userv.html
447    
448    P. Druschel and A. Rowstron. PAST: A largescale, persistent peer-to-peer
449    storage utility. In IEEE, editor, Eighth IEEE Workshop on Hot Topics in
450    Operating Systems (HotOS-VIII). May 20-23, 2001, Schloss Elmau, Germany,
451    pages 75-80, 1109 Spring Street, Suite 300, Silver Spring, MD 20910, USA,
452    2001. IEEE Computer Society Press.
453    
454    - Squirrel: a decentralized peer-to-peer web cache
455    - Feasibility of a Serverless Distributed File System Deployed on an Existing Set of Desktop PCs
456    - Distributed File Systems: Concepts and Example ('de facto article on DFS')
457    - Lotus Notes: ftp://ftp.lotus.com/pub/lotusweb/product/notes/G325-2061-00_j.pdf
458    - Open Hypermedia in a Peer-to-Peer Context
459    - Peer-to-Peer Hypertext
460    - Publius and Tangler publishing systems
461    - Mnet (ancestor: Mojo Nation), mnet.sourceforge.net
462    - Open problems in Data-Sharing Peer-to-Peer Systems
463    - Semantic Overlay Networks for P2P systems (a p2p 'version' of Xanalogical transclusions)
464    - Farsite Project (similar to CFS, PAST and Oceanstore)
465    
466    There was a good paper and demo about synchronous collaboration in ht01, but
467    is that out of scope here? (see pondering on limitations)
468    
469    
470    Pasted from IRC (Finnish)
471    =========================
472    
473  <hemppah:#gzz> antont: meidän pitää muuten antaa konkreettisia esimerkkejä  <hemppah:#gzz> antont: meidän pitää muuten antaa konkreettisia esimerkkejä
474  +artikkelissame colloborationista  +artikkelissame colloborationista
475  >#gzz> hemppah: toki. use caseja aattelin  >#gzz> hemppah: toki. use caseja aattelin

Legend:
Removed from v.1.2  
changed lines
  Added in v.1.3

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