A Namespace is like a mounted filesystem (see also
domain description). It contains a
hierarchical tree of information, which can be analogous to directories
and files. In addition to traditional file system structure and
content, a namespace can contain actions (ie. read, write) and
subjects (ie. users and groups), which define the dynamic
security policies of an application.
Namespaces are necessarily self-contained (or independent, if you
want). What this means is that a namespace cannot reference or contain
links to another namespace. A namespace is typically assigned
per-application, which effectively isolates its data and security
context from those of other applications.
There are seven different helpers (or high-level services, as
they are often called) offered to manage objects in a namespace:
|
| Structure |
| Security |
| Lock |
| Content |
| Macro |
| Index |
| Process |
These high-level services allow an application to access nodes in a
uniform fashion, no matter where the node might be located, or how the
store is phisically stored.
The helpers and the different objects they make available to the client
are the API provided to the client application. More details are given
in the Slide API section of the documentation.
In Slide, it is possible to define low-level services to control how
objects are stored, locked, ... This is because different kinds of
objects might need very different execution implementation, depending
how they are accessed, what they represent and so on.
Two different kinds of services exist :
|
| Descriptors store, which are responsible for storing structure,
locks, metadata, ... |
| Content store, which is only responsible for storing the content |
A distinction has been made, because it's easy to see that while some
repositories are very efficient at managing and indexing small amounts of
data (relational databases are a good example of this), others are best for
storing big chunks of data (filesystem, ...).
Within Slide, every object can possibly have a different kind of
backing low-level service. For example, some objects might be stored
in a remote LDAP directory, while others could be stored in an local
SQL database. Thus, the content of a namespace can be distributed
across several different descriptors/content store.
It is up to the administrator to choose how objects will be stored using
the Slide configuration file, which maps low-level services to
individual nodes in the namespace.
Services are attributed to nodes in the namespace. This mapping is
automatically inherited by sub-nodes. Here is an example of how one
namespace might be mapped into different services:
Namespace mapping onto different Low-Level Services
In this example, there are four different service mappings.
All actions are stored together, possibly in a memory store,
all files are stored in a specific store (possibly in a remote
FTP file server), while paul's files could be stored on his
own computer. The rest (/, /users and
/users/root in the example above) could be mapped into an
arbitrary SQL database.