added three old news posts

doc/news/2014-06-21_0.8.6.md

@@ -0,0 +1,204 @@
+# 0.8.6 Release #
+
+- author: Markus Raab
+- pubDate: Sat, 21 Jun 2014 12:00:00 +0100
+- shortDesc: adds technical previews & other improvements
+
+## Introduction ##
+
+The Elektra Initiative moved to Github for following reasons:
+
+- We were seriously missing a bug tracker
+- It may make collaboration easier
+- Build Server Integration:
+    - [Build on MergeRequests](http://build.libelektra.org:8080/job/elektra-mergerequests/) waits for the first merge request to be built!
+    - And the build status is now published [for this job](http://build.libelektra.org:8080/job/elektra-gcc47-all/)
+
+The main entrance point and URL for any advertisement and linking stays
+
+http://www.libelektra.org
+
+(which points to github at the moment).
+
+Additionally (not related to github), we now have a
+[LCOV code coverage report](http://doc.libelektra.org/coverage/latest/)!
+
+## Improvements ##
+
+The hosts plugin got documentation and several bug fixes.
+Multiline comments now remove the comment start sequences within
+the metadata comment.
+Additionally the kdb tool has an improved error message on invalid
+filenames. (thanks to Manuel Mausz)
+
+Fix a issue that the resolver plugin did not delete tmpfile in some
+error situations and add testcases with error plugin.
+
+Fix KS_END in C++ that did not specify the namespace.
+
+"kdb run_all" will now run all tests using Elektra from your system.
+Because not all testdata will be installed, some testcases fail unless
+you copy the data manually. Those are:
+testmod_yajl testmod_augeas testmod_fstab testmod_hosts test_xml
+
+Virtually all clang compiler warnings were fixed
+(thanks to Felix Berlakovich).
+
+kdb mv now is atomic. (API was used wrongly in the tool)
+
+Clang, icc and gcc are now all supported and tested.
+
+## Technical Previews ##
+
+A plugin that logs write operations and errors via the native
+journald interface was added (thanks to Felix Berlakovich).
+
+A preview of the augeas plugin was added. In cmake add "augeas" to PLUGINS
+and then run "kdb info augeas" for further instructions. Additionally,
+see Outlook below (thanks to Felix Berlakovich).
+
+A preview of python3 and lua bindings were added. In cmake enable the
+options BUILD_SWIG BUILD_SWIG_LUA BUILD_SWIG_PYTHON so that they are
+compiled (thanks to Manuel Mausz).
+
+The code generator was extended to support contextual values, more
+information about that topic later.
+
+The libtools library is back to life again! It has the same idea as its
+predecessor, but it is much more powerful. Because of the plugin system
+libtools is able to export and import any configuration format
+Elektra supports. Additionally it adds support for mounting backends.
+While most of its functionality is mature, the API is not final, though.
+
+## API Changes ##
+
+The API and ABI is as always backwards-compatible within the 0.8 series.
+
+This time it is, however, not forward-compatible (that means programs
+linked against 0.8.6 might not work with 0.8.5), because ksAtCursor()
+was added.
+
+ksAtCursor() provides the means for an external iterator. This
+was immediately exploited by an implementation of the C++
+iterators. These new C++(11) (reverse)iterators allow multi-pass
+algorithm over the same KeySet.
+
+ksSort was in the kdb.h header file, even though it never was
+needed nor available in 0.8. Automatic compatibility checkers may
+wrongly tell that the API is not compatible, but this is not the case
+(thanks to Manuel Mausz).
+
+The C++ API changed, including:
+- does not wrongly convert garbage to default types using ```get<T>```
+- getMeta now interally uses ```get<T>``` and both throw the
+  KeyTypeConversion Exception
+- KeySet::at directly allows one to use ksAtCursor()
+- KeyTypeConversion (or former KeyBadMeta) is not thrown anymore if key
+  is not available
+- Key::hasMeta allows one to directly check if metadata is available
+
+CMake: ENABLE_CXX11 is now default OFF (because gcc 4.6 and older won't
+       work with it). It disables some tests, though.
+unique_ptr will automatically be used instead of auto_ptr in this mode.
+
+Note for maintainers: libelektratools now needs to be installed so that
+the kdb tool will work.
+
+## Outlook ##
+
+One drawback of Elektra is the small number of available storage
+plugins. While writing storage plugins isn't too hard, it still requires
+knowledge of Elektras plugin architecture. In addition it is always
+necessary to keep both translation directions in mind (from file to
+Elektra and back).  In order to mitigate this issue Felix Berlakovich
+is working on an Elektra storage plugin which uses Augeas [1] to read
+and manipulate configuration files. Augeas uses a concept called lenses
+to translate between files and abstract trees (i.e. trees that hide
+unimportant details like whitespaces). In brief, what makes lenses special
+is the fact that they automatically disallow translations that cannot be
+reversed. This means that one of the translation directions comes for free
+as it is implicitly described by the other one. Therefore writing lenses
+is much simpler than programming both directions explicitly as done in
+traditional Elektra storage plugins.  Furthermore many lenses for common
+applications like Apache, MySQL, DHCPd and many more [2] already exist.
+Besides these benefits, Augeas lacks many features of Elektra. Although
+this is mostly intended because Augeas aims to concentrate just on
+configuration file manipulation some of these features would be valuable
+for administrators and developers. Some of these mentioned Elektra
+features include but are not limited to: logging of all configuration
+changes done, transformation of character encoding as needed, import and
+export of configuration data in any format, e.g. XML or JSON (Augeas has
+a similar feature for XML), file conflict detection and several different
+validations for configuration options (see [3] for a full list of
+features). With the Augeas storage plugin these features cannot be used
+with only the applications already integrated into Elektra, but with all
+applications for which lenses exist.  This storage plugin targets system
+administrators as well as developers, that wish to take advantage of
+Elektras features, but were unable to do so because of missing plugins. If
+no lens exists already, writing a new one requires neither programming
+skills nor knowledge of Elektras plugin architecture. Furthermore,
+implementing a new configuration file format is just a matter of writing a
+lens instead of writing a full-fledged parser.
+[1] http://augeas.net/
+[2] http://augeas.net/stock_lenses.html
+[3] http://www.libelektra.org
+
+Since Elektra is written in C, integration is limited to projects
+written in C and languages compatible with C like C++. In order to
+change this situation Manuel Mausz is working on the implementation of
+language bindings using two different techniques.  The first technique
+uses SWIG as a generic generator for various languages. In a nutshell,
+SWIG is a compiler that takes C/C++ declarations and creates the wrappers
+needed to access those declarations from other languages. The second
+technique is called GObject Introspection. In contrast to SWIG, GObject
+Introspection generates a language independent metadata file. For dynamic
+languages the GObject Introspection support in the target language will
+load this metadata file to generate bindings at runtime. In order to
+provide bindings for static languages a compiler on the metadate file
+will be used. This is comparable to using SWIG. Manuel will focus on
+implementing language bindings for Python and Lua though both techniques
+will support various other languages.  As language bindings only allow
+to call into Elektras API Manuel will also embed the interpreters of
+both Python and Lua into two generic plugins. Using these plugins in
+combination with the languages bindings it will be fully possible to
+write plugins for Elektra in languages other than C/C++.
+
+While Elektra offers sophisticated methods to store and manipulate
+configuration, currently there is only a command line tool (kdb)
+available to interact with the database. This requires the user to study
+and learn the possible commands and does not allow free exploration of the
+options of the application.  To enable new ways to interact with Elektra,
+Raffael Pancheri is designing and implementing a Graphical User Interface
+(GUI). To increase the probability to create a GUI that is indeed usable
+and beneficial, Pancheri is following the design principles proposed by
+Ben Shneiderman and Jakob Nielson.
+
+Finally, as you already noticed, Ian Donnelly is working on a semantic
+3-way merge to make distribution and package upgrades smoother.
+This is done as GSOC project. The progress is documented here:
+http://community.libelektra.org/wp/
+
+## Get It! ##
+
+You can download the release at:
+ http://www.markus-raab.org/ftp/elektra/releases/elektra-0.8.6.tar.gz
+
+- size: 1188337
+- md5sum: 4a59824e70a29295e9ef9ae7605d9299
+- sha1: 2570710b0057470223611ca00d61a0196e54e7b2
+- sha256: e815cf69b070c339784472841aa0ee0b169fab7c78f41cbbd7044f53fa9ed216
+
+Docu can be found here:
+ http://doc.libelektra.org/api/0.8.6/html/
+
+You can install the debian packages for debian (wheezy, amd64 only,
+some packages will be added later) by adding following lines to your
+/etc/apt/sources.list:
+ deb http://markus-raab.org/ftp/wheezy wheezy main
+
+and install or upgrade the packages with:
+ sudo apt-get update
+ sudo apt-get install libelektra-core4 libelektra-full4 libelektra-bin libelektra-dev libelektra-test libelektra-xmltool4 libelektra-json4 libelektra-dbus4 libelektra-doc
+
+Best regards,
+Markus

doc/news/2014-07-28_0.8.7.md

@@ -0,0 +1,135 @@
+# 0.8.7 release #
+
+- author: Markus Raab
+- pubDate: Mon, 28 Jul 2014 12:00:00 +0100
+- shortDesc: adds python2 bindings, 3-way merge & improvements
+
+Again, we managed to have a great feature release with dozens of
+corrections!
+
+## New Features ##
+
+Thanks to Manuel Mausz for further improving lua, python3 bindings
+and the new python2 bindings.
+
+The GSoC efforts have their first large contribution to Elektra, the 3
+way merge finally arrives with this release. It is still a long way to
+go, however, because augeas plugins can only be mounted with a
+workaround and the package integration of the 3-way merge is still in
+its infancy. More information about GSoC and its progress can be found
+[here](http://community.libelektra.org/wp).
+
+A special thanks to  Felix Berlakovich for his contributions to the
+3-way merge, including meta merging, conflict resolving strategies and
+extensive testing.
+
+Additionally, he added the plugins keytometa, ini and greatly improved
+the glob plugin. These plugins are technical previews and will receive
+some improvements in the next release, too.
+
+Now a script for tab completion is available
+[here](/scripts/scripts/kdb-bash-completion), again thanks to Felix
+Berlakovich.
+
+The contextual values now got a [tutorial]
+(https://github.com/ElektraInitiative/libelektra/tree/master/src/tools/gen)
+and small fixes.
+
+## Corrections ##
+
+Thanks to Pino Toscano for fixing a lot of spelling errors, simplify
+RPATH setting, respect $HOME and $TMPDIR, improvements of test cases,
+and his debian-packaging efforts.
+
+In the kdb tool not allowed subfolders are now checked properly
+and the output of warnings comes before output of the error.
+This fixes the problem that in the case of a longer list of
+warnings one did not see the error anymore.
+
+Fix compilation warnings on clang and gcc 4.9.
+Also improve test coverage on kdb tool and some plugins.
+
+Fix kdb import/export for some plugins (Should now work with any storage
+plugin again).
+
+kdb run_all should run flawlessly with this release. Remaining problems
+with not installed test data were fixed. kdb run_all also checks if the
+test cases do not modify any existing key and keeps a backup if this
+happened.
+
+Some remaining mem leaks in rare circumstances were fixed. Valgrind
+should now never report any leaks, if it does, please report the issue.
+
+## API Changes ##
+
+Added delMeta() for C++, because setMeta() with NULL will set the
+number 0 and not remove the meta.
+
+Arguments of isBelow, isDirectBelow, isBelowOrSame are swapped for
+better readability. k.isBelow(root) now means the obvious thing.
+The change only effects the C++ binding, keyIsBelow is unaffected by
+the change.
+
+## Documentation ##
+
+[Specification of metadata](doc/specification.ini) and
+[contracts](doc/contracts.ini) written/greatly improved.
+
+[Decisions](decisions) are introduced again.
+
+Most often the KeySet is ideal, e.g. when doing full iteration or when
+performing set operations. In some cases, however, a hierarchical data
+structure fits better. This is especially true for GUIs. Luckily, Keys
+can be in multiple data structures because of their reference counting.
+
+## Other Stuff ##
+
+We now fully embrace github:
+- We use its issue tracker (all issues from local text files were moved
+  there)
+- We have rewritten many READMEs to use githubs markdown
+- On pull requests the build server checks if the merge would break
+  the build.
+- All previous gitorious users are now at github. (Most had an account
+  anyway)
+
+Raffael Pancheri also made progress with its qt-gui. It now features a
+model that implements great parts of Elektra's features. Unfortunately
+the model cannot be serialised and thus changes cannot made persistent.
+Also undo and other important use-cases are still not there. The GUI
+looks very clean and was evaluated in a SUS study on 23.07.2014.
+The current implementation can be found [here]
+(https://github.com/0003088/qt-gui).
+
+Many distributions already have Elektra packages
+ - [Fedora](https://admin.fedoraproject.org/pkgdb/package/elektra/)
+ - [Gentoo](http://packages.gentoo.org/package/app-admin/elektra)
+ - [Arch Linux](https://aur.archlinux.org/packages/elektra/)
+
+In some distributions Elektra packages are available, but are not
+up-to-date. Pino Toscano is working on get them (actually
+Debian, but others are derived from it) up-to-date.
+ - [Ubuntu](https://launchpad.net/ubuntu/+source/elektra)
+ - [Debian](https://packages.debian.org/de/wheezy/libelektra3)
+ - [Linux Mint](http://community.linuxmint.com/software/view/elektra)
+
+A special thanks to Kai-Uwe Behrmann for providing packages for
+[CentOS, Fedora, OpenSUSE, RHEL and
+SLE](http://software.opensuse.org/download.html?project=home%3Abekun&package=elektra).
+
+## Get It! ##
+
+You can download the release from:
+
+http://www.markus-raab.org/ftp/elektra/releases/elektra-0.8.7.tar.gz
+size: 1566800
+md5sum: 4996df62942791373b192c793d912b4c
+sha1: 00887cc8edb3dea1bc110f69ea64f6b700c29402
+sha256: 698ebd41d540eb0c6427c17c13a6a0f03eef94655fbd40655c9b42d612ea1c9b
+
+already build API-Docu can be found here:
+
+http://doc.libelektra.org/api/0.8.7/html/
+
+Best regards,
+Markus

doc/news/2014-10-22_augeas.md

@@ -0,0 +1,56 @@
+# Augeas and Config::Model #
+
+- author: Markus Raab
+- guid: eca69e19-5ddb-438c-ac06-57c20b1a9160
+- pubDate: Mon, 22 Oct 2014 17:31:42 +0200
+
+A common question is: now we have Augeas for editing config files,
+why do we need Elektra, Config::Model or something else?
+
+First, it is clear that Augeas is a huge step forward and improved
+configuration of Linux systems, especially when used with centralized
+configuration management tools.
+
+Augeas, in short, introduces a special-purpose programming language that
+allows to transform configuration files into configuration trees and
+back. This transformation is it strength (so it is easy to add support
+for a particular legacy configuration files), but also it weakness (the
+mapping is implementation-defined by a language that is limited to a bit
+more than regular expressions). Augeas is not able nor is it intended
+to provide more abstraction over the configuration files. Instead Augeas
+mirrors the structure of the configuration as closely as possible.
+
+Elektra's goal, instead, is not only to provide access to legacy
+configuration files, but to provide access to the configuration
+exactly as the programs itself uses it. So with Elektra, the developers of
+applications are part of Elektra's ecosystem by providing specifications
+how their configuration should look like and by writing plugins that
+define how the configuration is accessed and checked. Ideally, after
+some time of legacy issues and migration, developers will also not
+have to care about writing plugins anymore, but just use any available
+ones (and users of their application can choose any other compatible
+plugin).  What is about to stay is a specification that defines the
+application's configuration, e.g. in INI (could be any syntax):
+
+    [/yourapp/file_dialog/show_hidden_files]
+    type=Boolean
+    default=true
+
+allows other applications to reuse your setting show_hidden_files by
+referring to above specification. So Elektra not only abstracts from
+cross-platform-related issues with an consistent API, but also allows
+us to be aware of other applications' configurations, leveraging easy
+application integration.
+
+Config::Model shares most of Elektra's goals, especially those regarding
+validation (you saw the type=Boolean above) and having a unified
+interface for all programs (this feature is unavoidable with any such
+approach). The projects mainly differs that Elektra is supposed to be used
+by the programs themselves (and not only by GUIs and validation tools)
+and that Elektra uses self-describing data: the specification itself
+is also in Elektra's key database, stored in metadata and e.g. below
+system/elektra/mountpoints. In Elektra validators can be
+written in any language (because the specification is just data)
+and can enforce constraints on any access (because plugins define
+the behaviour of the key database).
+