Unified configuration syntax

Background

Fenice started with a simple and plain configuration file for the global settings and then another syntax was used for the stream description and in feng we had to add another for the compositions.

The overall results are the following:

• we have three ugly hand made parsers for those syntaxes that had been almost fixed overall but remain pretty inflexible.
• we'll need to have others once we need to express/expose other features to the end user.
• users have to learn (and we have to document) many different syntax.

Abstract ideas

Main configuration

The main configuration must provide support for host and base virtuals, that means that the following structure should be presented: The main configuration will reside in a feng.conf file as was before, just the path would be $sysconfdir/feng/feng.conf and optionally additional sub configuration files (like module specific configurations) can stay in separate files and be included from the main feng.conf.

• main
  • global settings
    • priviledges
      • user
      • group
    • max session
    • log tag
    • log file
  • addresses
    • address1
      • ports
        • tcp ports
        • sctp ports
        • name1
          • root paths
          • max session
          • log tag
          • log file
          • acl conf
  • module specific setting
    • module1
      • option1
  • include files/dir

It should allow (maybe in a second time) support for including additional configuration files (like the include directive present in many languages) and merge the informations.

Resource configuration

The resource configuration should provide demuxer specific settings and additional information useful for the stream. There is a group of settings that is common to every demuxer. The resource configurations will be in substitution of the current .sd and .ds files, it will have a magic string on the first line to let the demuxer layer know it is a resource configuration without relying on the extension to guess which kind of file it is. They will reside in the avroot tree, each file name and path will be used as resource identifier.

• resource
  • aggregate
    • resource pointer stream_id
    • resource
      • …inline resource description
    • map
  • list
    • item
      • resource
      • time
        • start
        • stop
  • uri
  • metadata
    • name
    • author

    …

    • cc tag
  • overrides
    • sdp specific settings

Implementation

The main idea is to use just a single syntax across the configurations. Resources, global settings, per path settings will share the same parser, that has to possibly be a robust library, we have limited resources and I'd rather spend our time implementing streaming features than minimalistic parsers while full featured, fast and complete ones are available already.

XML based syntax

Pros:

• there are many stable and well known libraries
• Many people know it already
• there are tools around to validate the syntax given we create a schema/dtd for it.

Cons:

• It could be quite complex to hand write.
• Many people hate it

YAML based syntax

Pros:

• It is widely available across many different languages
• It is quite simple to compile by hand, yet as expressive as XML
• Provides all the facilities XML offers

Cons:

• there are just two C libraries available libyaml basically born as the core library for the python parser and syck again more focused on being used by other languages than being used directly.
• The mentioned libs are quite robust for our usage but their release aren't frequent.