Some enhanced ideas which (most likely) will not be part of 0.8
but should be decided until 1.0


== API Changes ==

ksClear/keyClear weg (da mit *Copy(,0) ersetzbar)
	meta handling should be the same

Single Interface: only get pointers, no memcopy (only one keyGetString, no
	keyString)

no "binary" metadata hack within API:
	just provide keyGetValue and keyGetValueSize
	no fixed strings when GetString on binary

remove old metadata get/set

remove null ptr checks? (see decision)

Start arrays with _ (and not with #)?

make KEY_END, ELEKTRA_PLUGIN_END also pointers and check them with
sentinel, have a single way how to terminate vaargs

_t is reserved by POSIX, so cursor_t, keyswitch_t and option_t
should be renamed to something elektra specific

size_t, ssize_t are not fixed size, use uint32_t.. to have no
problems on binary serialisation + unified behaviour (array sizes..)

empty/invalid keys should lead to an error in kdbGet

KEY_* -> KEY_O_* to avoid clashes
kdb.h -> elektra/kdb.h to avoid clashes

Remove/Refactor/Rename obsolete/not needed methods:
- keyClear
- keyGetRef
- keyRewindMeta
- keyNextMeta
- keyCurrentMeta
- keyCmp
- keyRel
- keyNeedSync
- keyIsBelow
- keyIsBelowOrSame
- keyIsDirectBelow
- keyIsInactive
- keyIsBinary
- keyIsString
- keyName
- keyGetFullNameSize
- keyGetFullName
- keyGetBaseNameSize
- keyGetBaseName
- keyValue
- keyString
- keyGetString
- keySetString
- keyGetBinary
- keySetBinary
- ksClear
- ksNeedSync
- ksCut
- ksPop
- ksHead
- ksTail
- ksLookupByName



== Conventions ==

conventions should be used everywhere

warnings should have array conventions #0, #10...


== Libraries ==

move meta data stuff to own library

move data structure to libelektra_keyset
move kdb to libelektra_kdb
move plugin functions to libelektra_plugin


so we would have:

 --------        --------
 | app  |        |plugin|
 --------        --------
    |               |
 -------------   ----------------
 |elektra_kdb|   |elektra_plugin|
 -------------   ----------------
          |        |
          ----------
              |
          ----------------   ------------------------
          |elektra_keyset|---|elektra_meta, tools,..|
          ----------------   ------------------------

+ no circular deps
+ linking against minimal interfaces (applications do not need plugin
  interface)



=== Plugin API Changes ===

maybe kdbConstruct and kdbDestruct needed too?

allow non-file/resolver based backends



== Error handling ==

translation of exceptions to different languages
(or by GUI only?) -> exporttranslations already exists



== Elektra types ==

customized type checkers
	which can be integrated within Frontend generator
	(for checking default values and preloading)
	maybe even checking of values within frontend


== Schema ==

convert elektra schema to xsd, yaml or similar
base schema (user/system)
plugins like fstab, hosts should provide their schema
schema for config of plugins + generation of code for them

define vectors, maps, class hierarchy
upgrade by global schema files similar to ldconfig


== Vision ==

Configuration definitions:
	provide definitions of known configuration trees
	generate code
	generate other schemas
	generate docu of comments (see libcomment)
	do mounting+preloading (generate config for type checkers)
	provide definitions which metadata is available and how it is used ("columns" of Configuration definitions)

community:
	make place to share configuration
	make place to share plugins

Make Plugins 1st level citizen
	plugins should be able to do everything the core can do
	(mounting, exceptions, bootstrapping, user/system split)

InternalDatabase: (only for frontend!)
	for highlevel kdbGetString, kdbSetString

Lazy+Bind Mounting
	makes kdbOpen cheaper (with many plugins)
	plugins can have global information bind mounted into their conf
	(e.g. /etc/passwd into resolver)
	kdbDup to copy current state (avoid multiple bootstrapping)
	leaves architecture as is -> possibility for any frontend and caching strategy + plays nicely with recursive plugins


Concurrent Plugin Processing:
	The plugins must be processed in the correct sequence because
	they change keys and have side effects.
	The processing of backends is however
	completely independent up to, and after, the commit step.
	Each of these two parts can be implemented concurrently.
	If any backend fails before commit, special care must be taken so
	that no backend commits its changes.
	The concurrent processing of the plugins
	is possible for both |kdbGet()| and |kdbSet()|.

GlobalPlugins:
	for notification start/end
	for typechecker, constraintchecker that needs global view
	for journaling
	for git-commit

non-file based storage plugins (backends):
	nvram
	sql
	mmap
	filesys

cryptography:
	sign modules and check them when kdbOpen
	encrypted keys backend
	sign+encrypt configurationn

distributed elektra
	automatical synchronisation of nodes

typed elektra
	typing system with subtyping
	dynamic type checking

notification: new notification api (only for frontend!)
	for highlevel API
	void kdbRegisterCallback(KeySet *interests, u_int32_t diffMask,
		KdbCallback *cb, void *userdata);
	void kdbUnregisterCallback(KeySet *interests, u_int32_t diffMask,
		KdbCallback *cb, void *userdata);
	void kdbDeliverEvents(long iterations, int sleep);


libelektra-metadata:
	multilanguage comments
	type of key (list, int, bool,...)
	validator of key (what is valid?)
	important? (-20 for optional 20 for must have)
	regexpr for keysets
	version of key (full.major.minor)
	user comments
	without any field it will be taken as
		comment for every language,
		not especially specified
	readonly?
	dynamic?
	persistent?
	visibility (enum for groups)
	default
	type
	description


== Multiple Files per Backend ==

The disadvantage of the current situation is that new files are not
tracked automatically (explicit mounting needed).

Storage plugins would need `KeySet` operations like difference to deduce which files to
remove or create.
The previously trivial test if an update is needed or a conflict occurred
may become slow depending on the number
of files involved.

For example, KDE has many configuration files in the path
`~/.kde/share/config`.
In a KDE installation with many programs it
can be up to one thousand individual files.


== User Mount Point Configuration ==

The mount point configuration resides only below
system/elektra/mountpoints. We decided against
providing \keyname{user/elektra/mountpoints} because of security concerns.
This issue, however, is solved because of the specification.
Now its possible to specify which namespaces should be used.

Still it must be assured that the user only mounts backends where he or she is
allowed to do so.
The administrator may still want to enforce some user
configuration. But this would be pointless if the user could circumvent
it.

Another open item is how, and if, user's own plugins can be used.
Plugins provided by the user open a door for code injection. These
problems have to be discussed and clarified before any attempts in this
direction are made.


== Distributing Configuration ==

Elektra currently does not provide any distribution or decentralised
features because it does not have any plugins communicating with a
configuration daemon.
These features are supposed to be on a higher level and not in backend
code. Instead, software like Cfengine and Puppet can use Elektra to change local
configuration.

Still, for some setups fetching configuration from other places or even
have a distributed key database is useful.


== Internals ==

BackendCtl:
	set and get options dynamically of backends
	readonly
	transactions
	locking (performance)
	filesys optimistic lock

support multiple owner at once for kdbGet()/kdbSet()? -> or just set USER env or uid?
allow mounting for users?


= FINISH for 1.0.0 =

only exported symbols should be available
Version info
release
minimize API -> (split core and convenience (e.g. libmetadata)?)


== OVERVIEW ==

draw a big picture

make list of all symbols
	exported symbols
	reduce it hard
	symbole, only export (otherwise static)
	Version info 4.0

