[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] manuscripts/pointers article.rst docutils.conf
From: |
Benja Fallenstein |
Subject: |
[Gzz-commits] manuscripts/pointers article.rst docutils.conf |
Date: |
Sat, 01 Nov 2003 21:49:38 -0500 |
CVSROOT: /cvsroot/gzz
Module name: manuscripts
Branch:
Changes by: Benja Fallenstein <address@hidden> 03/11/01 21:49:37
Modified files:
pointers : article.rst docutils.conf
Log message:
restructure (text not yet changed for it to make sense)
CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/pointers/article.rst.diff?tr1=1.66&tr2=1.67&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/pointers/docutils.conf.diff?tr1=1.2&tr2=1.3&r1=text&r2=text
Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.66
manuscripts/pointers/article.rst:1.67
--- manuscripts/pointers/article.rst:1.66 Sat Nov 1 21:43:12 2003
+++ manuscripts/pointers/article.rst Sat Nov 1 21:49:37 2003
@@ -345,17 +345,14 @@
.. Structure of this paper
The remainder of this paper is structured as follows.
-In Section 2, we introduce our fundamental, hash-based data model
-for a location-independent Web. In Section 3, we propose
-a versioning system built on top of this data model.
+In Section 2, we introduce pointer records.
+In Section 3, we propose a simple, hash-based data model
+that can be used by P2P Web servers and clients.
In Section 4, we introduce a scheme for storing only
-the differences between versions that works with our
-basic data model, making the storage of past versions
-more economical. In Section 5, we outline solutions
-to the permanency issues raised by the use of
-cryptographic keys (which may be stolen or lost).
-In Section 6 we discuss our implemenation, and
-Section 7 concludes.
+the differences between versions, built on our basic
+data model. In Section 5 we discuss other possible applications
+of pointer records, and Section 6 gives an overview of our
+implementation. Section 7 concludes.
@@ -432,68 +429,6 @@
.. ??? XXX I don't understand the above AT ALL
-Primitive block storage abstraction
-===================================
-
-Our goal is to build a complete system of versioning
-on top of the following primitive abstraction provided
-by a system:
-
-Add permanent block
- Given a bit string and a MIME type,
- adds the block into
- the system and return a *permanent id* for
- that exact bitstring,
- for example a cryptographic hash of the data.
-
-Get the permanent data for a given id
- Given a permanent id, locate and return the bitstring
- stored with that permanent id, or inform the caller
- that the data was not currently available.
-
-Global reverse indices
- The ability to define (on a system-wide basis)
- partial functions of blocks (of the data in the bitstrings)
- and to query for the ids
- (and thus the data)
- of the blocks with the given values for the functions.
-
-For scalability, the ability to also define another
-function, which takes a set of blocks and determines which
-of the blocks are "relevant" locally on each peer can yield
-great improvements.
-
-Managing where the blocks are stored is excluded
-from the scope of this abstraction. The versioning system
-must work as best it can even if only a subset of the
-blocks is available.
-
-The benefits of starting from this basic model are numerous:
-
-- simple to implement - existing models cover this well
-
-- can be made to work with peers that join and leave small
- ad hoc networks often (and the global "net" less often)
-
-- robust - all state of the system is in the blocks
-
-In this framework, we shall define a system of *pointers*:
-some types of identifiers that refer to a block but whose
-referent may be changed. In the following Sections, we show
-how a reasonably efficient system can be constructed
-using only the primitive datablock model given above.
-
-.. - Basic model of underlying system: Only blocks
- - Benefits of that, in a nutshell
- - Reverse indexing (nicely provided through structured overlays),
- *define* reverse indexing
- - Def.: Pointers are abstract references that *point*
- to different blocks (versions) over time
- - Storm is designed to be modular; different routing algorithms
- can be used with Storm for locating data with loc.ind. ids (
- (e.g., PAST and CFS are tightly binded to their routing
- algorithm)
-
Pointer records
===============
@@ -571,6 +506,70 @@
too [XXX is this still a point
given that OceanStorm does something similar?] think
+
+Primitive block storage abstraction
+===================================
+
+Our goal is to build a complete system of versioning
+on top of the following primitive abstraction provided
+by a system:
+
+Add permanent block
+ Given a bit string and a MIME type,
+ adds the block into
+ the system and return a *permanent id* for
+ that exact bitstring,
+ for example a cryptographic hash of the data.
+
+Get the permanent data for a given id
+ Given a permanent id, locate and return the bitstring
+ stored with that permanent id, or inform the caller
+ that the data was not currently available.
+
+Global reverse indices
+ The ability to define (on a system-wide basis)
+ partial functions of blocks (of the data in the bitstrings)
+ and to query for the ids
+ (and thus the data)
+ of the blocks with the given values for the functions.
+
+For scalability, the ability to also define another
+function, which takes a set of blocks and determines which
+of the blocks are "relevant" locally on each peer can yield
+great improvements.
+
+Managing where the blocks are stored is excluded
+from the scope of this abstraction. The versioning system
+must work as best it can even if only a subset of the
+blocks is available.
+
+The benefits of starting from this basic model are numerous:
+
+- simple to implement - existing models cover this well
+
+- can be made to work with peers that join and leave small
+ ad hoc networks often (and the global "net" less often)
+
+- robust - all state of the system is in the blocks
+
+In this framework, we shall define a system of *pointers*:
+some types of identifiers that refer to a block but whose
+referent may be changed. In the following Sections, we show
+how a reasonably efficient system can be constructed
+using only the primitive datablock model given above.
+
+.. - Basic model of underlying system: Only blocks
+ - Benefits of that, in a nutshell
+ - Reverse indexing (nicely provided through structured overlays),
+ *define* reverse indexing
+ - Def.: Pointers are abstract references that *point*
+ to different blocks (versions) over time
+ - Storm is designed to be modular; different routing algorithms
+ can be used with Storm for locating data with loc.ind. ids (
+ (e.g., PAST and CFS are tightly binded to their routing
+ algorithm)
+
+
Diffs
=====
@@ -580,6 +579,12 @@
takes 500 KB)
- old idea: storing only differences
- XXX
+
+
+Applications
+============
+
+XXX
Implementation
Index: manuscripts/pointers/docutils.conf
diff -u manuscripts/pointers/docutils.conf:1.2
manuscripts/pointers/docutils.conf:1.3
--- manuscripts/pointers/docutils.conf:1.2 Thu Oct 30 03:41:50 2003
+++ manuscripts/pointers/docutils.conf Sat Nov 1 21:49:37 2003
@@ -1,8 +1,13 @@
-#$Id: docutils.conf,v 1.2 2003/10/30 08:41:50 tjl Exp $
+#$Id: docutils.conf,v 1.3 2003/11/02 02:49:37 benja Exp $
[options]
-stylesheet-path = article.css
+stylesheet-path: article.css
+
+source-link:
+datestamp:
+generator:
+
# LaTeX
documentclass: article
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gzz-commits] manuscripts/pointers article.rst docutils.conf,
Benja Fallenstein <=