[PC-BSD Dev] RFC: Choice of a Less Error-Prone Scripting Language for Configuration Scripts + Standard Data Format

Rob Messick robmessick at gmail.com
Thu Mar 7 17:23:23 PST 2013


 I would love to see a tool that could be used to apply and manage 
custom configurations on one or many PCBSD machines.

Why re-invent the wheel? There are quite a number of configuration 
management solutions out there that have a head start on this task.  We 
use puppet at work but are working on switching towards salt 
(http://saltstack.com/community.html), an MIT licensed configuration 
management and remote execution framework written in Python. Salt uses 
YAML for defining congurations and has a number of FreeBSD modules.  
The sysutils/py-salt port has about 15 other packages as dependencies.  
Salt is just one option, obviously there are a handful of configuration 
management tools that could be used.

-Rob


On Thu 07 Mar 2013 02:35:41 PM PST, Torsten Eichstädt wrote:
>
>
> Hello to all!
>
>
>
> [The following proposal is meant for one of the next releases, not for
>
> immediate hacking of existent code, of course!]
>
>
>
> REQUEST FOR COMMENT
>
>
>
> - DRAFT -
>
>
>
> I propose to
>
>
>
> 1. Re-write and refactor the configuration & installation scripts in
> PCBSD in a less error-prone scripting language than shell script.
>
> Suggestions: Lua or JavaScript;
>
>
>
> 2. Change the configuration data files to a standardized,
> human-readable and
>
> simple data format. My suggestions are YAML or JSON.
>
>
>
>
>
> RATIONALE:
>
> It is common sense that shell scripts lack built-in support for
>
> modularisation and test capabilities, and are especially weak concerning
>
> string handling, fault-tolerance, re-usability and maintainability;
> this is
>
> only a partial list of inherent weaknesses. Thus, it is commonly believed
>
> that once a project gets bigger, shell script's weaknesses prevail their
>
> advantages; they become a risk and should be replaced by an advanced,
>
> superior (scripting) language.
>
>
>
> Currently, many backends throughout the PC-BSD configuration &
> installation handling are implemented as shell scripts, and their
> inherent weaknesses are the root cause of many -- often subtle and/or
> trivial but nasty -- bugs. In particular, robust string- and exception
> handling are major requirements of configuration handling. Many
> experienced developers add built-in test capabilities to this list.
>
>
>
> Using a more advanced scripting language would certainly improve the
>
> situation, especially concerning the topics noted above.
>
>
>
> Then, the use of a standardized data format for configuration data is a
>
> simple practical consideration: Programming libraries exist
>
> - to test the validity of the data and the data files,
>
> - to read and write syntactically correct data files robustly.
>
>
>
> Thus, through the use of such well tested, mature libraries, a
> standardized,
>
> simple data format will improve robustness and fault-tolerance.
>
>
>
>
>
> DETAILS:
>
> For the two formats I propose, YAML or JSON, libraries for shell
> scripts are
>
> available as well; thus, their use is independent from changing the
>
> configuration & installation scripts to another language.
>
>
>
> I propose to pick one scripting language and one data format throughout
>
> PCBSD configuration (if at all possible). JSON is (mostly) a subset of
> YAML.
>
> Both are (more or less) simple, platform-independent, human-readable, and
>
> widely supported in all major programming languages.
>
>
>
> Up to my current research, YAML has the advantage to allow comments; but
>
> there's probably an easy work-around for JSON by simply including a field
>
> named "comment" or "note" of type "string" where needed.
>
> JSON allows for code injection in JavaScript, whereas YAML explicitely
>
> inhibits this. There are pros and cons concerning this. For security,
> it's a
>
> no-go, for practical reasons it can sometimes be of advantage.
>
>
>
> JavaScript has on it's side a cleaner syntax for exception handling
> and that
>
> it is used in QML, and QML certainly is a very appealing choice for
> GUI-fied
>
> configuration tools. Nevertheless, bindings for Lua to Qt exist, and the
>
> interpreter is very small. Both languages are well-founded, widely
> used, easy
>
> to learn, and allow for rapid development cycles as they are scripted.
> Many
>
> open-source modules and libraries are readily available to prevent the
>
> developer from reinventing the wheel.
>
> --
>
> =|o)
>
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.pcbsd.org
> http://lists.pcbsd.org/mailman/listinfo/dev


More information about the Dev mailing list