[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Branch:         
Changes by:     Hermanni Hyytiälä <address@hidden>      03/10/08 09:24:49

Modified files:
        Documentation/misc/hemppah-progradu: masterthesis.tex 

Log message:
        Barbara's comments #3

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.209&tr2=1.210&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.209 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.210
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.209      Wed Oct 
 8 08:59:43 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Wed Oct  8 
09:24:48 2003
@@ -1598,22 +1598,22 @@
 \chapter{Fenfire hypermedia system}
 
 In this chapter we give an overview of the Fenfire system and 
-the xanalogical storage model. Also, we describe Storm 
+the xanalogical storage model. Also, we describe Storm, 
 which is an essential part of Fenfire's Peer-to-Peer functionality. 
 
 \section{Overview}
 
-The Fenfire project \cite{fenfireurl} is an effort to build a location 
transparent, hyperstructured desktop 
-environment. By location transparent, we mean hiding the heterogeneous and 
distributed nature of the system
-so that it appears to the end user like one system, and by hyperstructured 
system
-a system in which data can be associated with other data arbitrarily. Fenfire 
uses xanalogical storage model 
-\cite{ted-xu-model} as a basis for hyperstructured media. Each data item in 
the Fenfire system has a globally unique 
+The Fenfire project \cite{fenfireurl} is an effort to build a 
location--transparent, hyperstructured desktop 
+environment. By \emph{location transparent}, we mean the heterogeneous and 
distributed nature of the system is hidden
+so that it appears to the end user like one system, and a 
\emph{hyperstructured system}
+is one in which data can be associated arbitrarily with other data. Fenfire 
uses a xanalogical storage model 
+\cite{ted-xu-model} as the basis for hyperstructured media. Each data item in 
the Fenfire system has a globally unique 
 identifier. This property allows making references between \emph{any} 
 data easier and more seamlessly interoperating than in other systems. For 
location transparency in the Fenfire system, 
-we are currently analysing the applicability of Peer-to-Peer infrastructure. 
+we are currently analysing the applicability of the Peer-to-Peer 
infrastructure. 
 
-Fenfire was formerly also a partial implementation 
-of the ZigZag\texttrademark -- structure, which has been originally invented 
+Fenfire was formerly a partial implementation 
+of the ZigZag\texttrademark --structure, which has been originally invented 
 by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF) 
\cite{w3rdfurl}
 for representing internal data structures and their relationships. 
 
@@ -1633,16 +1633,16 @@
 
 \section{Xanalogical storage model}
 
-Xanalogical storage model \cite{nelson99xanalogicalneeded} is a different kind 
of model for 
-presenting data and relationships between data. For example, in the World Wide 
Web links are
-between documents, while in the xanalogical storage model links are between 
individual 
+The xanalogical storage model \cite{nelson99xanalogicalneeded} is a different 
kind of model for 
+presenting data and relationships between data. For example,  World Wide Web 
links are
+between documents, while the xanalogical storage model links are between 
individual 
 characters\footnote{Xanalogical storage model
 is not limited to text. It can support arbitrary data, e.g., pixels of picture 
or 
-frames of video.}. \emph{Enfilade} is a mutable ''virtual file'' (or part of 
one), which is a list 
+frames of video.}. Enfilade is a mutable ''virtual file'' (or part of one), 
which is a list 
 of fluid media content. Fluid media is the smallest unit of data in the 
xanalogical storage
-model (e.g., a character). \emph{Transclusion} is an inclusion in 
-enfilade of contents already used in another enfilade. With the transclusion, 
a system 
-implementing the xanalogical storage model is able to show \emph{all} data 
content that share the same 
+model (e.g., a character). Transclusion refers to the inclusion  
+of enfilade content that is already used in another enfilade. With the 
transclusion, a system 
+implementing the xanalogical storage model is able to show all of its data 
content that share the same 
 fluid media with current data content (e.g., all documents in a system 
containing document's text). 
 Figure \ref{fig:xanalogical_model} 
 illustrates the xanalogical storage model with documents, text and characters.
@@ -1651,14 +1651,14 @@
 and bidirectional. A link is shown between any two data contents 
 containing a specific fluid media unit that the link connects.
 Each fluid media unit in the xanalogical storage model has a
-permanent, globally unique identifier. For instance, let's consider the 
following
-example, presented first time in \cite{lukka02freenetguids}: ''the character 
'D' 
-typed by Janne Kujala on 10/8/97 8:37:18''. When character 
+permanent, globally unique identifier. For instance, consider the following
+example, presented originally by Lukka et al. \cite{lukka02freenetguids}: 
''the character 'D' 
+typed by Janne Kujala on 10/8/97 8:37:18.'' When the character 
 'D' is first typed in, the xanalogical storage model
 creates a permanent identifier for that character 
 and retains it when the character is copied to different document. In 
practice, the xanalogical 
-storage model uses \emph{spans}, ranges of consecutive
-fluid media units to perform storage operations. 
+storage model uses spans, ranges of consecutive
+fluid media units, to perform storage operations. 
 
 \begin{figure}
 \centering
@@ -1670,45 +1670,43 @@
 
 \section{Storm}
 
-In this section, we will give a brief overview of Storm design. More 
information can be found
-from recent publications. For detailed Storm design, see 
\cite{fallenstein03storm}.
+This section present a brief overview of the Storm design. More detailed 
information can be found
+from the recent work by Fallenstein et al. \cite{fallenstein03storm}.
 
-Storm (for \emph{STORage Module}) stores all data as \emph{blocks}, which
-are immutable byte sequences. Storm \emph{assigns} a globally unique 
identifier to each
-block\footnote{This resembles the process how tightly structured overlay 
assigns a subset of keys
+Storm (for STORage Module) stores all data as ''blocks'', which
+are immutable byte sequences. Storm assigns a globally unique identifier to 
each
+block\footnote{This resembles the process how a tightly structured overlay 
assigns a subset of keys
 to each participating peer: a user has no control over the assignment 
process.}. SHA-1 cryptographic 
 content hash function\footnote{SHA-1 is 
-considered as a collision free hash function. Therefore, it is very unlikely 
that two different Storm blocks 
+considered a collision free hash function. Therefore, it is very unlikely that 
two different Storm blocks 
 would have same identifier.} \cite{fips-sha-1} is used
-for creating unstructured and semantic-free, globally unique identifiers for 
blocks. Because of SHA-1
-content hash, all identifiers are directly the data verifiers as well. The 
uniqueness of blocks creates 
-a basis for implementing the xanalogical storage model in the Fenfire system. 
Storm blocks have in common with regular files as they
-both contain the data. The main difference is that Storm blocks are 
\emph{immutable} since any 
+for creating unstructured and semantic-free, globally unique identifiers for 
blocks. Because of the SHA-1
+content hash, all identifiers are the data verifiers as well. The uniqueness 
of blocks creates 
+a basis for implementing the xanalogical storage model in the Fenfire system. 
Storm blocks are similar to with regular files as they
+both contain the data. The chief difference is that Storm blocks are 
\emph{immutable} since any 
 change to the byte sequence would change block's hash value (i.e., globally 
unique identifier).  
 
 Support for immutable data is built on the immutable abstraction. Storm uses
-\emph{pointers} and \emph{diffs} for dealing with this kind of data. Using 
diffs
+pointers and diffs for dealing with this kind of data. Using diffs
 we are able to store alternative versions of Storm blocks efficiently. In this 
 paper, however, we discuss only pointers as they are part of the thesis' 
research problems. 
-More information about diffs can be found from \cite{fallenstein03storm}. 
  
-\emph{Pointer} \cite{benja02urn5, fallenstein03storm} is a semantic-free 
updatable reference to 
-Storm block. Pointer is a unique reference to the data and it is usually 
+A pointer \cite{benja02urn5, fallenstein03storm} is a semantic-free updatable 
reference to 
+a Storm block that is a unique reference to the data and is usually 
 represented as a random string. Storm pointers are rather a \emph{concept} of 
data (e.g., ''The front page of the most recent 
 version of New York Times newspaper'') whereas blocks \emph{contain} the data 
 (''New York Times newspaper, 10.10.2002, version 1.0'').
 Figure \ref{fig:storm_model} illustrates Storm storage model with pointers. 
 
-Each pointer is \emph{linked} to a collection of \emph{pointer blocks}. 
-Pointers can be created by a user, before the creation of a data block. 
Pointer blocks 
+Each pointer is linked to a collection of pointer blocks. 
+Pointers can be created by a user, before creating of a data block. Pointer 
blocks also
 are created automatically by Storm when a data block is created and associated 
with a pointer 
 (e.g., a user creates a data block associated with the concept ''The front 
page of the most recent 
-version of New York Times newspaper''). Pointer block has always a single 
target (i.e., a data block), 
-saying that pointer $P$ targets data block $B$. In addition to this, pointer 
block 
-may contain a list of zero or more obsoleted pointer blocks: when a new 
version of pointer 
-block is created, it supersedes one older version which has been created in 
the past using the Storm indexing
-mechanisms. For details, see \cite{fallenstein03storm}. Next 
-time, when the pointer is used for referring to a specific data block, only 
+version of New York Times newspaper''). A pointer block has always a single 
target (i.e., a data block), 
+saying that pointer $P$ targets data block $B$. In addition to this, a pointer 
block 
+may contain a list of one or more obsoleted pointer blocks: when a new version 
of pointer 
+block is created, it supersedes one older version that has been created in the 
past using the Storm indexing
+mechanisms. When the pointer is used for referring to a specific data block, 
only 
 the most recent pointer's block target is loaded. However, the pointer blocks 
pointing
 to the previous versions of data blocks remains accessible, if needed. In 
figure \ref{fig:storm_pointercreation}, 
 we show the overall pointer creation process.