Voting starts in March for the Drupal Association Board election.
There are a few things in Drupal that resemble a key/value store, I've been thinking it'd be nice to add a centralized API to unify some of this.
The overall plan is to introduce a concept of pluggable storage that is separate from the specific subsystem that is being swapped out. In practice it is likely that both will need to be, but it might still allow code to be shared for either different subsystem backends or different storage backends or both of these. And we'll get consistency even if neither of those happen.
Things that might be able to build on a shared API:
Form state storage (currently mis-uses cache system)
Update module cache (currently re-implements cache system)
Possibly even entities could build off this for basic CRUD.
On top of this there are projects like http://drupal.org/project/memcache - this actually provides integration with two different libraries (the memcached and memcache PECL extensions have different feature sets and APIs), and currently does so via it's own dmemcache.inc. Potentially we could get to the point where the cache.inc/lock.inc included with the memcache project are generic and you could swap in a non-memcache library (APC? something else?) for just the storage - or swap the store and extend a couple of methods at least.
Haven't worked up any code yet, this is just notes for now and there are definitely things to work through before it can be viable.
Things that would be needed, not necessarily all in the base interface(s)/classe(s) though:
Concept of tables/bins/collections - pass this to the constructor like cache.inc does now.
Ability to create tables/bins/collections
Ability to require tables/bins/collections to be disk-backed.
We already have per-field storage and per-cache-bin storage so that could do with being central or at least possible to implement.
Zend and possibly some other frameworks have been separating their read and write interfaces into separate classes (KeyValueReader + KeyValueWriter) which I assume is for code weight reduction on read requests.
At least these methods make sense for most stuff.
->set($key, $value, ($expires?))
->garbageCollection() (needed for SQL and MongoDB at least if we add expires)
Maybe ->add() (insert as opposed to merge)?
FAILED: [[SimpleTest]]: [MySQL] 41,115 pass(es), 1 fail(s), and 0 exception(s). View
FAILED: [[SimpleTest]]: [MySQL] 41,114 pass(es), 1 fail(s), and 0 exception(s). View
FAILED: [[SimpleTest]]: [MySQL] 41,118 pass(es), 1 fail(s), and 0 exception(s). View
FAILED: [[SimpleTest]]: [MySQL] 41,117 pass(es), 1 fail(s), and 0 exception(s). View
PASSED: [[SimpleTest]]: [MySQL] 39,800 pass(es). View