
Config Delta
	delta between lists in a config object

		$c->
		
	delta between objects (with lists)
		=> can be done in two steps
		
	accept callback from caller 
		pass object to caller for introspection
		caller pass arguments to callback
		default callback is a dumper
			default dumper can also get arguments


use Debug::Mixin

Dependencies between configuration variables are complex as the dependency is build with Perl
can we extract the dependency via B:: call stack and history?

Shall Parents allow override instead for children forcing the override
	or shall we force an unlock and an override?
	or shall we add a die if override
	
Die if precedence given option
Die if override option (how does lock work in this case) 
Die if variable unset in GetConfig
Die if variable not existst in GetConfig

can we override a locked variable => yes, no warnings (except override)

write a bunch of examples in a cookbook (take them from tests)
	particularly show the warning errors
	explain how to inherit from config to config
	
#Add validation
can we define a validator for an already existing configuration variable, yes
do we inherit validators, between what?
Can a validator be used for cross variable dependency? preferably something added externally
can we have multiple validators (good)
does a new validator check for an already existing value? should
Can we use the same mechanism for user validators and C::I validators (IE override ...)
are validators per variable or per category? variable
	remember where validators are added

	We may want to define validators before we create a config

	GetConfig shall NOT return an invalid value if the validator was set after the value

	Set
	NAME ...
	VALIDATORS => [sub, ...]

	VALIDATORS =>
		[
		{
		CATEGORY_NAMES => ['CLI', 'CURRENT',] ,
		NAMES          => ['CC', 'LD'],
		VALIDATORS     => {alphanumeric => \&alphanumeric,},
		},
		],

#History should have its name (including where it was created (package, node sub, ...)) at the bottom to help read it
	can use comments
	
#Packages that do not modify a config variable shall not be in the previous history
	not part of this module as history is handled manually

# ----------------------------
# We need to be able to get a config's history accross packages.
	#This means we need to be able to link histories together. Possibily link
	config together.

	#A naive approach is to copy the history from parent to child. This will
	use memory but will guarantee isolation.

	#Setting history should only be allowed once before the variable is defined


#'precedence given to X::Y'  should be 'X::Y takes precedence'

#when a class override another:
	do we need to use override again next time?
	shall we display a warning if override is not set
	this is how it worked in 0.01
	=> force it to override
	
#variable history should be extracted accross the categories in the right order

#what happends when setting an overriden variable?
	#does it stay overriden? yes
	is a warning generated? yes


#Add option to warn if lower level config will be ignored
	IE: setting a local variable would display a warning about the non local variable
	CHECK_LOWER_LEVEL_CATEGORIES
	
#Warning when categories are used explicitely by the user
	setable through a sub 
	SetDisplayExplicitCategoryWarningOption
	WARN_FOR_EXPLICIT_CATEGORY

#Is category used in Get?
#Get should return where the config is comming from (GET_CATEGORY)
#Config category dump should be done in hierarchical order
#status message and displayed messages differ slightly. 
	#use the same variable
	#multiple lines are displayed when multiple higher priority entries are
		encountered, display a single header footer
# An empty history string is added when the value is identical
#Check number of element in all subs to avoid 'odd number of ...' message
# OK Do we need 'force lock' to unlock 
#OK Can we set a protected category variable?
#We should be able to add a comment to the history entry when setting a
	variable
#lock status is not added to history when locking is done through 'set'. 
	OK when	done through 'lock'
#typo in GetCategories example
#Do we keep a history of warnings (protected, ignored, ...) and should it be an option

# ----------------------------

#test utilities
#wantarray
#locked categories
#custom get
#custom Get Hash ref
#document  code
#=head1 TEST, COVERAGE and EXAMPLES
#test pod, syntax, critic ...
#coverage
#check the extra test modules in Xmas proj
#check all coverage tests and make them real tests
#Manifest, README, ...

test distribution release manifest ??.

check in SVK

log4j support
