[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...
From: |
Hermanni Hyytiälä |
Subject: |
[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert... |
Date: |
Wed, 08 Oct 2003 09:24:50 -0400 |
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.