Drupal KeyValueStore - Room for (heavy) API changes + joining forces?

[sun]

Aloha! :)

The Drupal community searched for a simple, straightforward KeyValueStore component for quite some time, and for some reason, this project here did not appear for anyone in any results... Today, it suddenly appeared.

Either way, we started to hack on our own: KeyValueStore — which really has the most simple focus and goal of providing a consistent and coherent interface for various key/value storages, so they can be plugged into other components/subsystems (such as Drupal's cache and configuration subsystems).

As such, it is a really "trivial" abstraction, which only exists for the purpose of empowering other components with a variety of possible k/v storages. The need for it arose as we were starting to abstract the very same storage "pluggability" for multiple subsystems in Drupal core, kinda duplicating the same code. We're still in an early development stage and in the process of merging the most current and "best" code into the component though.

So here's the thing: As you can see in that repo, there are a couple of similarities — at least with regard to the low-level storages. ;) I directly need to amend that we do not have any use for the mapping of data onto PHP objects, which seems to be the primary focus and goal of your code... whereas our primary focus is on the plain CRUDL operations.

In turn, we asked ourselves whether there is any room for bringing the basic key/value storage abstraction in line and joining forces on that? — and possibly moving that PHP object mapping into another/separate component? :)

What do you think? :)

Cheers,
sun

[beberlei]

That is surely possible, this api is very unstable still and we can still do whatever is necessary to get to a point where this component gets very useful :)