== kdb usecases ==


1.) Refetch same config (not supported for multiple keysets)

kdbOpen()

kdbGet()

kdbGet()

kdbClose()



2.) Initialize with any config (not supported)

kdbOpen()

kdbSet()

kdbClose()



->   Semantics could be more general, because others (without timestamp + state if kdbGet was done before) would return other results! (1.0 semantics for non-file based config)



Desired semantics: get gets what set has done before, kdbOpen() and kdbClose() should not matter at all (stateless)



Additional/optional desired semantics: kdbGet() again with same keyset should not produce IO (allowed and important optimization)

kdbSet() again with same keyset should not produce IO



applications should be unaware which backends are working

(only exception: kdbGet() might return more+kdbSet() need whole keyset handed over before if no changes are desired)



->   Needed because mountpoints could be anywhere and it is not efficient to cache everything internally




== cache vs. non-cache ==

internal caches lead to duplication of memory consumption
(could be avoided by reference counting)

in some cases caches cannot be avoided?
 -> filesys, databases?

cache discussion:
+ not more keys than needed
+ kdbGet avoids IO even if done somewhere else
+ KDB handles could be more locally
- not possible to access cache with current architecture, KDB high level API
- implementation overhead
- where should the caches be
