0.8.4 Release

I am proud to announce this amazing feature release!

Elektra now speaks json!
From this release on, Elektra has full read and write capabilities
towards the world of json. json is a very popular serialization format
which is originated in Javascript.
It is very similar to the already existing tcl plugin, which also works
like a parser without intermediate datastructures. But unlike the tcl
plugin, where a grammar was written, the blazing fast yajl library was
used.

Elektra now has convention for arrays!
Multiplicity is a very common need within configuration. Json specifically
has syntactic support for it. Up to now Elektra used different conventions
for arrays. E.g. Mountpoints name their plugins #0-#9, and fstab had
#00-#99 lines. These approaches
always limited to  number of predefined elements.

The new convention solves the problem: #0-#9 (unmodified to be compatible
with mountpoints) is followed by #_10-#_99, continuing with #__100 -
#__999 and so on. It gets a bit long for large arrays, but they are
supposedly not edited by hand anyway.  This approach has the big advantage
that it works without modifying the sort order for the KeySet., which
cannot be done for two reasons:

1.) Backwards compatibility: It would break applications which count on
5 being ordered after 12. The compatibility problem could be tackled in
Elektra 0.9, but:

2.) Slower comparison is the main issue. Elektra heavily depends on
comparing keys. It is needed for inserting, lookups and other KeySet
operations.
Currently comparison is done by strcmp() which is highly optimized on
most platforms. When numbers need some special handling, strcmp() could
not be used anymore.

POSIX compatibility and handling of multi-process conflicts has
been improved. Now the HOME environment variable will be used. The
old behaviour (USER environment variable) is still available as
fallback. Additionally there is a fallback for embedded systems to the
hardcoded variant. In case of these fallbacks a warning will be added.

A new plugin uname was added. It allows you to mount the functionality
of uname within Elektra's key/value namespace. Currently it is read-only
and needs POSIX.

The built-in description of plugins, especially for new plugins, was
extended and improved. It is now also possible to output the description
by:
 kdb info <plugin> description
e.g.
 kdb info yajl description

Two new kdb commands were added:
 kdb file
allows you to print out the configuration file where a given key is located.

 kdb sget
guarantees you to get a value which is handy in shell scripts.


Now a large test suite makes sure that the kdb tool works without
troubles. Many bugs, especially concerning resolver and mounting, were
fixed. The list is way too long to put it here, see git log for details.


The build server now has a job searching for TODOs:
 http://build.libelektra.org:8080/job/elektra-todo/

The latest documentation from git master is also build there and the
results are published here:
 http://doc.libelektra.org/api/latest/html

The current release is always documented at:
 http://doc.libelektra.org/api/current/html




---------------

Roadmap

Exciting times for software integration for free operating systems:
After some years of more or less deep sleep I will reactivate the
initiative so that we finally can lay a foundation for a truly integrated
system. During my PhD I will have time to remove the larger barriers and
tackle some fundamental problems.

The targets will be:
- Embedded: Elektra is on the frontier for embedded systems because of
  its tiny core and the many possibilities with it's plugins.
- Server: Elektra is ideal suited for a local configuration storage by
  mounting existing configuration files into the global tree. Nodes
  using Elektra can be connected by already existing configuration
  management tools.
- Desktop: Elektra allows applications to read and write from a global
  configuration tree. Missing is a description (schema) so that these
  values actually can be shared.

Quality Goals will be:
- Extensibility: Requirements for configuration can vary a lot.
  The only common dominator are key/value pairs, nearly everything else
  can differ from project to project. So Elektra needs to be, and is,
  very extensible to fulfil this wide range of goals.
- Simplicity: The system should be very simple in its core so that it
  can be understood easily. Complexity should be hidden in optional
  extensions. The full system should work out-of-the-box as much as
  possible. With these properties it should also be as safe and
  fault-tolerant as possible.
- Performance: Features will not be used if they impact performance too
  hard. So Elektra and it's extensions are designed to perform well with
  a minimum amount of syscalls with an emphasis on retrieving configuration
  fast.


The roadmap for Elektra's implementation has three steps:

1.) Elektra 0.8
Is the current stable release branch. It will get continuous development
with releases at least every two month. They focus will be on stability,
better user experience, integration of new programming languages and
more serialize formats.
Some ideas:
- serializer: e.g. json, using lenses
- resolver: e.g. xdg with improved locking
- testing: automated abi compatibility checks, shell test suite
- bindings: gobject, swig
- more tutorials and explanations
- more advertisement (e.g. conferences)
- creating applications using Elektra
- schema for configuration
- more tool support, e.g. GUIs
- and much more...
(see also doc/todo/CURRENT and doc/todo/TODO in repo)

If you are interested in working on one of these topics, please contact me.
It will also be possible for students to write a thesis solving problems
concerning those ideas.

2.) Elektra 0.9 (starting around 2014)
This will be a development branch which will coexist next to 0.8. In it
all features will emerge which are too large for the 0.8 branch, like
changes in the core and the plugin system. Some of them might be "boring
and academical" :-)
The branch will lead to releases which can be considered as technology
previews. They will be most likely not intended to be used in a
production environment.
Some ideas:
- allow plugins to be first level citizens
- allow plugins to nest in each other
- allow non-file based plugins
- Next generation of type system allowing user defined types, subtypes,
  units and constraints
- Next generation of contracts which allow recursive nesting and
  auto-negotiation of capabilities
- and much more...
(see also doc/todo/FUTURE in repo)

Those tasks will be done by me, but ideas and discussions are always
appreciated.

3.) Elektra 1.0
This will basically a stable snapshot of 0.9 when there is no doubt that
Elektra can be extended without breaking your (the customers) way to
deal with configuration.
Some ideas:
- API cleanup
- build an environment around the libraries
- build sharing platforms for configuration
- extend the foundations created in 0.9
- and much more...

More information will be published soon, so stay tuned.


---------------

0.8.3 Release

This release mostly brings improvements in the release process, the test framework and
new debian packages.

A benchmark showed that rereading the same database only needs
about 2ms and the syscalls needed are quite optimal.

The debian folder is now removed from master repository,
but instead a release and debian branch was created.
See doc/GIT for new policy of branches.
Thanks to Christian Amsüss <chrysn@fsfe.org>
for all tips, suggestions and help.
The git branches are done like in arandr.
0.8.2 was skipped because a git tag was placed wrongly
when the new release scheme was tried out on Monday June
18 2012.
The tag was removed later.

kdb export now works nicely, use
 kdb export <path> simpleini
to show key = value pairs.
Additionally kdb umount was added.

A cmake bug was fixed, so that "make test" now
works immediately.

The kdbconfig.h and kdbos.h received some needed cleaning
up. The HAVE_ macros are now set correctly by cmake, Elektra's
macros are prefixed with KDB_ and not needed macros were
removed.

Some docu was improved and some typos fixed.
Thanks to Erkan Yilmaz <erkan77@gmail.com> for
two fixes.

The test framework now has built-in support for comparing keysets and
keys together with its metadata. Because of usage of macros the
linenumber will be stated correctly for comparison.

Additionally also a script test framework was started.

The documentation was updated and improved at some places.

The build system was improved. Now also ALL, NODEP or DEFAULT are
accepted as magic values for a list of plugins.

Most of the tests run automatically on a buildserver:
http://build.libelektra.org:8080/

It gives you an good impression with how many different compilers elektra
is currently tested. Elektra now also compiles with clang.

You can download the release at:
http://www.markus-raab.org/ftp/elektra/releases/elektra-0.8.3.tar.gz
md5sum: d6b1d668a1a1e155137d4ebc1bd0d5d7
sha256: 48fab82a6b1e8f0038c43ae9ade4da25b697d0aa74e39b7b94056ab7febc4be1

You can install the debian packages for debian squeeze (i386 and amd64 only) by
adding following lines to your /etc/apt/sources.list:
deb     http://build.libelektra.org/debian/ elektra-release-glue main
deb-src http://build.libelektra.org/debian/ elektra-release-glue main

and install all or some of the packages with:
sudo apt-get install libelektra-core4 libelektra-full4 libelektra-bin libelektra-dev libelektra-test libelektra-xmltool4

Have fun!



---------------


0.8.1 Release

The 0.8.1 brings some bugfixes and many small improvements.

The only new feature is that "kdb export" can now be used with any
storage plugin.  This is useful for backups, but also as replacement of
the former "kdb-ls -l" which showed keys and values.
 kdb export <name> simpleini
now does this job. For a full export of system configuration to xml,
you can use:
 kdb export system xmltool

The "kdb get" and "kdb getmeta" tool now support -n and --no-newline to
suppress the newline at the end of the output.

The cmake installation pathes got a overhaul and are now documented
more properly in COMPILE.  Noteworthy is that plugins and include files
can also be installed directly in the system library or include path.
Additionally the build system now handles multiarch systems by supporting
LIB_SUFFIX.

FindPackage of cmake and pkgconfig remain the best methods to use elektra
from external application. New are the examples for such projects in
the folder "external".

The -H and --help support of the kdb tool were still improved, some typos
fixed and some information updated. Additionally the warning output got
some cleanup to be less confusing.

The user experience was improved. The ".kdb" or ".config" directory now
will be created if they do not exist.

The debian packages are now splitted to have full advantage of the
new plugin system.  The core packages (libelektra, libelektra-dev and
libelektra-bin) do not depend on libxml anymore.  New is the package
libelektra-full, which contains a single dynamic library containing all
plugins statically.  A repository will be announced separately.

There was also some cleanup of old files, like the old highlevel-api
(which does not exist anymore). Finally the API documentation, especially
for plugin developers, was improved.







---------------






0.8.0

Finally it is done, 0.8.0 is finished.
Even though it has a very similar API to 0.7.0
(see APICHANGES) the implementation changed
paradigm-shifting.
0.8.0 introduces a completely new plugin framework,
which allows you to check types and structure
of the keys, notify by dbus, log to syslog,
change the way how filenames are resolved and change
the configuration format and files at runtime.

The C-API, like defined in
 src/include/kdb.h
and also the one to plugins, as defined in
 src/include/kdbplugin.h
is considered to be stable within this 0.8.0 release.


Elektra has a new presence at freedesktop, see
 http://www.freedesktop.org/wiki/Software/Elektra

Download it from:
http://www.markus-raab.org/ftp/elektra/releases/elektra-0.8.0.tar.gz
ftp://www.markus-raab.org/elektra/releases/elektra-0.8.0.tar.gz





---------------






0.7.0

Finally it is done, the 0.7.0 API is finished.
The API covers everything shown in kdb.h and all
releases in 0.7.0 will be 100% ABI and API compatible
supported for at least a year.

Some bugs might break that rule, but there should not be
left many anymore, because every method is at least checked
twice and most have hundred of test cases.
Please report any bugs you find to http://bugs.libelektra.org
- portability and build bugs
- mistakes, misspelling in documentation

This is not valid for kdb-tools, there are lots of bugs
remaining there and a rewrite would be very useful.

For that reason there will be a separate release for
kdb-tools, libelektratools and the backend interface.

The stable APIs of libelektratools and the backend interface
will be announced separately, but they will be part of 0.7.x.

kdb-tool and kdbedit and so will also have separate
releases, but because they are not a library there
is no API or ABI issue there.

Pages related to 0.7.0:
http://www.libelektra.org/GetStartedMounting
http://www.libelektra.org/Tutorial
http://www.libelektra.org/API-Changes0.7
http://www.libelektra.org/Changes0.7

Marketing issues:
- Freshmeat announcment
- Sourceforge upload
- API docu upload
- forums
- newsgroups
- other mailinglists

Download it from:
http://www.markus-raab.org/ftp/elektra-0.7.0.tar.gz
ftp://www.markus-raab.org/elektra-0.7.0.tar.gz







---------------




0.7.0rc5 The last release candidate before 0.7.0

I am proud to present the finished  0.7.0 external API in
kdb.h [0].

A lot changed to 0.6.10 but the fundamentals are clearer then
ever before: 3 Classes with their methods, a clear, easy and
mature API. It is very hard to use it wrong but you get
best results with very short code:

http://www.libelektra.org/Tutorial

Other parts are not finished, like libelektratools, the
kdb-tool and the backend interface. They are not part of
the official 0.7 release and get their own release later.

The reasons to release within the next week are:
 - The API is finished
 - Oyranos needs a stable release from elektra
 - the last release is long ago
 - unstable has been much more stable than stable since some time
 - there have been no commits to the stable branch since
   unstable existed
 - Elektra grows just too complex to wait for all parts to finish

Now some highlights from one month of work from 333 ChangeLog
lines:
 - many many bugs were fixed
 - the core completely compiles with -ansi -pedantic -std=c99
 - all code compiles with -Wall -Werror
 - the test-suite is now complete
 - much cleaner infrastructure within the code
 - many autoconf/automake issues fixed
 - static, dynamic building, linking with defaults backends
   everything works!
 - many new options to stat and remove all keys and so on..
 - environment variables and passwd database allow subtle
   influence of where the user configuration resides
 - kdb info now prints where configuration lies on hard disc




---------------




0.7.0rc4 - 12.05.2008
I am proud to present the fourth release candidate of elektra
0.7.0.

It is now possible to enable and disable Backends and Bindings
with configure switches. The documentation was improved.
The c++ binding now basically works, see the tests for examples.
Ini and Berkleydb backends now compile again.
There were a lot of bug fixes, like mntent.h fix for Mac OS X.




---------------




0.7.0rc3 - 24.04.2008
Call for 0.7 finish

Unfortunately there is not much response about the 0.7 release
candidates but there is still a lot to do to have a mature
library worth to be announced as stable.

Specifically there are following things to do and we really need
help to achieve that faster than end of this year:

There are now only 3 backends working well tested but undistinguished
in handling error scenarios. At least 3 more Backends are needed
also tested in real world applications. Favoured are existing but
not ported backends like berkleydb, ini, winregistry and uniconf.

Working bindings have a lot meaning in how complete and useful
the API is. It would be preferable to have at least 3 bindings
working with at least an example application like kdb-tool.
They could be cpp, python and one open.

A lot of bug squashing is left open. Please don't hesitate to open
and fix more bugs on http://bugs.libelektra.org.

Documentation is not yet completely updated to 0.7. Especially the
homepage has a lot of outdated information, but also the API documentation
needs another eye on it and the tutorial needs a rewrite.

There might be some licencing issues in some parts of elektra,
everything should be BSD, if you find something please open a bug.

A partial blocker is the kdb-tool, where a rewrite would be nice but
is not necessary for 0.7 (the library counts not the environment).

Other things like portability are taken seriously but are not blockers,
they can be fixed later too.

What is really good working in elektra is the infrastructure like
svn, homepage, bug tracking, many thanks to José Luis Tallón for
that!

Now some words about 0.7.0rc3:

Version macros were added to have static information about
the elektra version compiled against. There were many
enhancements in the C++ Binding, the Key Class is now
quite well complete.

While writing the C++ binding I realized that there is need
for keyInc() the opposite of keyDel() to increase the
viability of a key object.

keyVNew() and ksVNew() were added to make it possible to pass
the va_list from the C++ binding.

The blocker bug that libelektra assumes system/elektra/mountpoints
to exist was solved, many thanks to Patrick Sabin. The tests
now work without any preloading without memory leaks.

And lots of bug fixes (Many thanks to Kai-Uwe Behrmann):
- sed changed for macosx compatibility
- fixed signature ssize_t ksToStream
- also set CXXFlags
- fix wrong parent at end in ksToStream
- fix return value of successful kdb import
- string is default type for xml without type=""
- fix extra_dist some missing files
- remove , at end of enumeration lists

The svn id is unstable@1352:
https://svn.libelektra.org/svn/elektra/unstable/

The release candidate is available under:
http://www.markus-raab.org/ftp/elektra-0.7.0rc3.tar.gz



---------------



0.7.0rc2 - 23.03.2008
Second Release Candidate of unstable repository.

We proudly present the second release candidate for Elektra 0.7.0. Many
bugs were fixed, kdbGet() and kdbSet() is now really stable, useful and
well documentated. test_kdb also tests hosts and fstab next to filesys
with 6598 test cases.

kdbSet() now supports a parent key to only set a part of the
configuration passed by the keyset, allowing to e.g. save system and
user configuration seperately. It only calls kdbSet_backend() when it
is actually necessary. The splitting works much more efficient with n*b
instead of n^2*b.

The highlevel functions kdbGetKey() and kdbSetKey() now work well with
Capabilities. This allows very easy changing of keys inside backends
even with some lacking capabilities, see GetStartedMounting.

Patrick Sabin and I wrote our bachelor thesis about mounting backends for
configuration. It gives a detailed introduction in problem and choices
and the actual implementation.
See: doc/elektra.pdf doc/elektra.ps.gz





---------------




0.7.0rc1 - 06.12.2007
First Release Candidate of unstable repository.
= Large Changes =

== Multiple Backends ==

Elektra now supports multiple backends at once. That means every path
like user/sw or system/filesystems can reside in a different backend.

Use cases for backend mounting: 1. There are many configurationfiles lying
on every system that can't be replaced for various reasons. These files
can be fade in into the global elektra namespace without any notice by
applications using these files. Backends for /etc/fstab, /etc/mtab and
/etc/passwd exist right now.

2. Users or administrators might get used by ordained files or syntax
without wanting to change the whole configuration using elektra. The
mounting technique allows them to choose.

3. Specific programs may have very complex and large configuration. Binary
files with index may give them a fairly better performance without
missing the connection to the global namespace.

4. Configuration provided by network or local daemons for notification
and caching can't be used for every program. Configuration related to
bootup or some system users need to be available without them, but should
also be accessed by applications needing configuration from network.

If you are not convinced - Its just about choice and you can go on using
only one backend.

See http://www.libelektra.org/Backends what is and might be possible.

== kdbOpen(), kdbClose(), kdbGet() and kdbSet() ==

These 4 core functions do now everything related to backend
communication. All the other functions are build upon it. This makes
backend writing much easier. Removing and Stat works by setting a flag
in a key.

KDB * is now a typedef for the _KDB structure and not a
void* pointer.

== Keyset ==

Starting with ksNew you can give a hint how large the keyset may grow. You
can also give a list of keys which should be added at startup.

ksGenerate() makes use out of that and generates you a keyset in C-Code
which you can use in your applications or for regression testing.

The internal structure of keyset is now a growing (and shrinking)
array. Keys may belong to multiple keysets now. The last ksDel() deletes
the key automatically (reference counter).

This implementation is a lot faster, the benchmark is for 0.7.0rc1 better
then for 0.6.*, even though the mounting logic takes a bit of performance,
but very little and something about zero when no backend is mounted.

== Key ==

The key now uses sizes for name, owner, value and comment. This allows a
complete new technique of serializing: keyCompose(). With that you can
serialize a key without a single malloc(). keySerialize() is rewritten
for the new key struct too.

== Access Types ==

The directory is now marked by the executable flags. That means you can
disallow other users or groups to list your keys.

== Capabilites ==

Some backends fullfill the whole specification of kdbGet_template() and
kdbSet_template() and can be used by any program for any purpose. Other
backends have principle limitations and do not fullfill the specification,
but can do more than enough to be useful.

To handle this problem we created a data structure describing what
capabilites a backend does not have. With that technique you can use the
testing framework from early steps developing the backend on. To do so,
just declare your backend can do nothing and delete step by step while
your backend evolves.

== Testing framework ==

There is now a large testing framework with 11 collections with up to
8128 tests each. Most conditions of the whole sourcecode are checked,
that means if you random change something in the code you have a good
chance that a test case will fail.

There are 2 new flags:
 --enable-valgrind-tests
   Allows you to enable valgrind for testing, a full list of memory
   leaks is printed after every test.
 --enable-gcov
   Use it to see what lines of code are covered by tests.

The testcases are without any memory leak (dozens of leaks are fixed,
especially in xml code).

---------------

0.6.10 - 10.03.2007 Elektra received some stability updated from Patrice
Dumas.

---------------

0.6.6 - 21.12.2006 support for directories with values and comments on
filesys, berkeleydb and daemon backends.

---------------

0.6.4 - 08.09.2006 Tons of improvements and standarizations to the build
system from Patrice Dumas and Yannick.  Many improvements to the daemon
backend from Yannick.  Several other bug fixes.  We are getting closer
to a production daemon.

---------------

0.6.2 - 02.06.2006 - Includes more robust key name handling and
intelligent duplicate "/" removal - Escaping of "/" on key names is
now supported - Better automatic UTF-8 conversions - More tunnings for
better future daemon backend support - More robust berkeleydb backend -
Backends are now installed on /lib/elektra/ - The build system was tunned
to be included as a Fedora Extras package

---------------

0.6.0 - 30.03.2006 Public release of the new API.  Check it out in SF.
