1598 |
\chapter{Fenfire hypermedia system} |
\chapter{Fenfire hypermedia system} |
1599 |
|
|
1600 |
In this chapter we give an overview of the Fenfire system and |
In this chapter we give an overview of the Fenfire system and |
1601 |
the xanalogical storage model. Also, we describe Storm |
the xanalogical storage model. Also, we describe Storm, |
1602 |
which is an essential part of Fenfire's Peer-to-Peer functionality. |
which is an essential part of Fenfire's Peer-to-Peer functionality. |
1603 |
|
|
1604 |
\section{Overview} |
\section{Overview} |
1605 |
|
|
1606 |
The Fenfire project \cite{fenfireurl} is an effort to build a location transparent, hyperstructured desktop |
The Fenfire project \cite{fenfireurl} is an effort to build a location--transparent, hyperstructured desktop |
1607 |
environment. By location transparent, we mean hiding the heterogeneous and distributed nature of the system |
environment. By \emph{location transparent}, we mean the heterogeneous and distributed nature of the system is hidden |
1608 |
so that it appears to the end user like one system, and by hyperstructured system |
so that it appears to the end user like one system, and a \emph{hyperstructured system} |
1609 |
a system in which data can be associated with other data arbitrarily. Fenfire uses xanalogical storage model |
is one in which data can be associated arbitrarily with other data. Fenfire uses a xanalogical storage model |
1610 |
\cite{ted-xu-model} as a basis for hyperstructured media. Each data item in the Fenfire system has a globally unique |
\cite{ted-xu-model} as the basis for hyperstructured media. Each data item in the Fenfire system has a globally unique |
1611 |
identifier. This property allows making references between \emph{any} |
identifier. This property allows making references between \emph{any} |
1612 |
data easier and more seamlessly interoperating than in other systems. For location transparency in the Fenfire system, |
data easier and more seamlessly interoperating than in other systems. For location transparency in the Fenfire system, |
1613 |
we are currently analysing the applicability of Peer-to-Peer infrastructure. |
we are currently analysing the applicability of the Peer-to-Peer infrastructure. |
1614 |
|
|
1615 |
Fenfire was formerly also a partial implementation |
Fenfire was formerly a partial implementation |
1616 |
of the ZigZag\texttrademark -- structure, which has been originally invented |
of the ZigZag\texttrademark --structure, which has been originally invented |
1617 |
by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF) \cite{w3rdfurl} |
by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF) \cite{w3rdfurl} |
1618 |
for representing internal data structures and their relationships. |
for representing internal data structures and their relationships. |
1619 |
|
|
1633 |
|
|
1634 |
\section{Xanalogical storage model} |
\section{Xanalogical storage model} |
1635 |
|
|
1636 |
Xanalogical storage model \cite{nelson99xanalogicalneeded} is a different kind of model for |
The xanalogical storage model \cite{nelson99xanalogicalneeded} is a different kind of model for |
1637 |
presenting data and relationships between data. For example, in the World Wide Web links are |
presenting data and relationships between data. For example, World Wide Web links are |
1638 |
between documents, while in the xanalogical storage model links are between individual |
between documents, while the xanalogical storage model links are between individual |
1639 |
characters\footnote{Xanalogical storage model |
characters\footnote{Xanalogical storage model |
1640 |
is not limited to text. It can support arbitrary data, e.g., pixels of picture or |
is not limited to text. It can support arbitrary data, e.g., pixels of picture or |
1641 |
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 |
1642 |
of fluid media content. Fluid media is the smallest unit of data in the xanalogical storage |
of fluid media content. Fluid media is the smallest unit of data in the xanalogical storage |
1643 |
model (e.g., a character). \emph{Transclusion} is an inclusion in |
model (e.g., a character). Transclusion refers to the inclusion |
1644 |
enfilade of contents already used in another enfilade. With the transclusion, a system |
of enfilade content that is already used in another enfilade. With the transclusion, a system |
1645 |
implementing the xanalogical storage model is able to show \emph{all} data content that share the same |
implementing the xanalogical storage model is able to show all of its data content that share the same |
1646 |
fluid media with current data content (e.g., all documents in a system containing document's text). |
fluid media with current data content (e.g., all documents in a system containing document's text). |
1647 |
Figure \ref{fig:xanalogical_model} |
Figure \ref{fig:xanalogical_model} |
1648 |
illustrates the xanalogical storage model with documents, text and characters. |
illustrates the xanalogical storage model with documents, text and characters. |
1651 |
and bidirectional. A link is shown between any two data contents |
and bidirectional. A link is shown between any two data contents |
1652 |
containing a specific fluid media unit that the link connects. |
containing a specific fluid media unit that the link connects. |
1653 |
Each fluid media unit in the xanalogical storage model has a |
Each fluid media unit in the xanalogical storage model has a |
1654 |
permanent, globally unique identifier. For instance, let's consider the following |
permanent, globally unique identifier. For instance, consider the following |
1655 |
example, presented first time in \cite{lukka02freenetguids}: ''the character 'D' |
example, presented originally by Lukka et al. \cite{lukka02freenetguids}: ''the character 'D' |
1656 |
typed by Janne Kujala on 10/8/97 8:37:18''. When character |
typed by Janne Kujala on 10/8/97 8:37:18.'' When the character |
1657 |
'D' is first typed in, the xanalogical storage model |
'D' is first typed in, the xanalogical storage model |
1658 |
creates a permanent identifier for that character |
creates a permanent identifier for that character |
1659 |
and retains it when the character is copied to different document. In practice, the xanalogical |
and retains it when the character is copied to different document. In practice, the xanalogical |
1660 |
storage model uses \emph{spans}, ranges of consecutive |
storage model uses spans, ranges of consecutive |
1661 |
fluid media units to perform storage operations. |
fluid media units, to perform storage operations. |
1662 |
|
|
1663 |
\begin{figure} |
\begin{figure} |
1664 |
\centering |
\centering |
1670 |
|
|
1671 |
\section{Storm} |
\section{Storm} |
1672 |
|
|
1673 |
In this section, we will give a brief overview of Storm design. More information can be found |
This section present a brief overview of the Storm design. More detailed information can be found |
1674 |
from recent publications. For detailed Storm design, see \cite{fallenstein03storm}. |
from the recent work by Fallenstein et al. \cite{fallenstein03storm}. |
1675 |
|
|
1676 |
Storm (for \emph{STORage Module}) stores all data as \emph{blocks}, which |
Storm (for STORage Module) stores all data as ''blocks'', which |
1677 |
are immutable byte sequences. Storm \emph{assigns} a globally unique identifier to each |
are immutable byte sequences. Storm assigns a globally unique identifier to each |
1678 |
block\footnote{This resembles the process how tightly structured overlay assigns a subset of keys |
block\footnote{This resembles the process how a tightly structured overlay assigns a subset of keys |
1679 |
to each participating peer: a user has no control over the assignment process.}. SHA-1 cryptographic |
to each participating peer: a user has no control over the assignment process.}. SHA-1 cryptographic |
1680 |
content hash function\footnote{SHA-1 is |
content hash function\footnote{SHA-1 is |
1681 |
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 |
1682 |
would have same identifier.} \cite{fips-sha-1} is used |
would have same identifier.} \cite{fips-sha-1} is used |
1683 |
for creating unstructured and semantic-free, globally unique identifiers for blocks. Because of SHA-1 |
for creating unstructured and semantic-free, globally unique identifiers for blocks. Because of the SHA-1 |
1684 |
content hash, all identifiers are directly the data verifiers as well. The uniqueness of blocks creates |
content hash, all identifiers are the data verifiers as well. The uniqueness of blocks creates |
1685 |
a basis for implementing the xanalogical storage model in the Fenfire system. Storm blocks have in common with regular files as they |
a basis for implementing the xanalogical storage model in the Fenfire system. Storm blocks are similar to with regular files as they |
1686 |
both contain the data. The main difference is that Storm blocks are \emph{immutable} since any |
both contain the data. The chief difference is that Storm blocks are \emph{immutable} since any |
1687 |
change to the byte sequence would change block's hash value (i.e., globally unique identifier). |
change to the byte sequence would change block's hash value (i.e., globally unique identifier). |
1688 |
|
|
1689 |
Support for immutable data is built on the immutable abstraction. Storm uses |
Support for immutable data is built on the immutable abstraction. Storm uses |
1690 |
\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 |
1691 |
we are able to store alternative versions of Storm blocks efficiently. In this |
we are able to store alternative versions of Storm blocks efficiently. In this |
1692 |
paper, however, we discuss only pointers as they are part of the thesis' research problems. |
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}. |
|
1693 |
|
|
1694 |
\emph{Pointer} \cite{benja02urn5, fallenstein03storm} is a semantic-free updatable reference to |
A pointer \cite{benja02urn5, fallenstein03storm} is a semantic-free updatable reference to |
1695 |
Storm block. Pointer is a unique reference to the data and it is usually |
a Storm block that is a unique reference to the data and is usually |
1696 |
represented as a random string. Storm pointers are rather a \emph{concept} of data (e.g., ''The front page of the most recent |
represented as a random string. Storm pointers are rather a \emph{concept} of data (e.g., ''The front page of the most recent |
1697 |
version of New York Times newspaper'') whereas blocks \emph{contain} the data |
version of New York Times newspaper'') whereas blocks \emph{contain} the data |
1698 |
(''New York Times newspaper, 10.10.2002, version 1.0''). |
(''New York Times newspaper, 10.10.2002, version 1.0''). |
1699 |
Figure \ref{fig:storm_model} illustrates Storm storage model with pointers. |
Figure \ref{fig:storm_model} illustrates Storm storage model with pointers. |
1700 |
|
|
1701 |
Each pointer is \emph{linked} to a collection of \emph{pointer blocks}. |
Each pointer is linked to a collection of pointer blocks. |
1702 |
Pointers can be created by a user, before the creation of a data block. Pointer blocks |
Pointers can be created by a user, before creating of a data block. Pointer blocks also |
1703 |
are created automatically by Storm when a data block is created and associated with a pointer |
are created automatically by Storm when a data block is created and associated with a pointer |
1704 |
(e.g., a user creates a data block associated with the concept ''The front page of the most recent |
(e.g., a user creates a data block associated with the concept ''The front page of the most recent |
1705 |
version of New York Times newspaper''). Pointer block has always a single target (i.e., a data block), |
version of New York Times newspaper''). A pointer block has always a single target (i.e., a data block), |
1706 |
saying that pointer $P$ targets data block $B$. In addition to this, pointer block |
saying that pointer $P$ targets data block $B$. In addition to this, a pointer block |
1707 |
may contain a list of zero or more obsoleted pointer blocks: when a new version of pointer |
may contain a list of one or more obsoleted pointer blocks: when a new version of pointer |
1708 |
block is created, it supersedes one older version which has been created in the past using the Storm indexing |
block is created, it supersedes one older version that has been created in the past using the Storm indexing |
1709 |
mechanisms. For details, see \cite{fallenstein03storm}. Next |
mechanisms. When the pointer is used for referring to a specific data block, only |
|
time, when the pointer is used for referring to a specific data block, only |
|
1710 |
the most recent pointer's block target is loaded. However, the pointer blocks pointing |
the most recent pointer's block target is loaded. However, the pointer blocks pointing |
1711 |
to the previous versions of data blocks remains accessible, if needed. In figure \ref{fig:storm_pointercreation}, |
to the previous versions of data blocks remains accessible, if needed. In figure \ref{fig:storm_pointercreation}, |
1712 |
we show the overall pointer creation process. |
we show the overall pointer creation process. |