Fster-xml-configuration-file

FSter XML configuration file

The configuration file allows to define what the user will see in FSter directories.
Having the file in place is mandatory and it is read by default from /etc/fster/fster.xml
The configuration file must follow XML 1.0 standards

XML schema (xsd)

In order to simplify editing and verification of custom configuration files, we have prepared the XML schema of the configuration file.
Download FSter configuration schema: FSter.xsd

Here we show initial part of this schema: the conf tag.

conf schema

Configuration concepts

The configuration has the following main concepts:

Trees

Trees are the first elements of the configuration, under the conf tag. There are two kinds of tree:

  • the exposing tree, that describes what users will see in the folder hierarchy through FSter;
  • the saving tree, that describes how FSter will store real files created on the filesystem. Note: at the moment it is only possible to configure the saving tree base_path (by default files will be saved in ~/.fster_saving/)

Content objects

An exposing tree is structured in objects that can be used to define the folder hierarchy and which files to show. These are called content objects.

Some content objects can contain other content objects:

  • folder
    shows a folder for each RDF subject in the repository matching with defined conditions (i.e., specific predicates and objects);
  • static_folder
    shows a single folder with a static name;
  • set_folder
    shows a folder for each value assumed by the specified RDF predicate in the store;

some other can not:

  • file
    shows a file for each RDF subject in the repository matching with defined conditions (i.e., specific predicats and objects);
  • mirror_content
    maps 1:1 a folder from the effective filesystem, and all his underlaying hierarchy
  • system_folders
    similar to mirror_content with a base_path = “/”

The exposing tree starts with a root, under the conf tag: it is a static_folder content object (the name tag, if defined, will be ignored).

Policies

Each content has its policy allowing the user to define what FSter must expose and what it will allow to do.
We have defined 2 kinds of policy:

  • the visualization policy that defines what FSter will show (hierarchy, names, file contents);
  • the editing policy that defines what FSter will allow to do (i.e., create, modify, delete) on the content to which the policy is applied.

Inheritance

The hierarchical structure defined with content tags, described above, allows different policies for each content: we can define policies so that a content can inherit policies from its parents.
In the visualization policy we can then use:

  • inheritable_conditions, to apply the defined conditions to all the enclosed content objects;
  • self_conditions, that apply the defined conditions only to the current content object.

In the editing_policy we can use:

  • the inheritable_metadata, to add the defined metadata to all the children.

Use cases

These are the latest published complete xml examples:

  • FSter Media Library
    The configuration permits you to navigate and use media files, that you have on your harddisk, organized by images, audio and video
  • FSter Music Library
    The configuration permits you to navigate and use music files, that you have on you harddisk, organized by artist, album or genre.

Here the complete list of the use cases

XML short examples

Here we collect some xml short examples:

Last edited by Roberto Guido