Reserved memcached key namespace

[Brad Fitzpatrick]

I like it. (if the resultant code is clean...)

Changed the reserved prefix is easy later... don't let that block you. :)

- Brad


On Wed, 2 May 2007, Marc wrote:

> Lately it seems to me that it would be a lot easier to add features and keep
> clients small and simple if we used a reserved part of the memcached key
> namespace for admin and status operations.  Consider stats, version,
> flush_all and flush_regex.  Rather than implementing a new message format,
> one would simply set or get keys from the reserved namespace.
>
>    quit\r\n
>
>    becomes:
>
>    set __quit__ 0 0\r\n\r\n =>
>        <= STORED\r\n
>
>    version\r\n
>
>    becomes:
>
>    get __version__\r\n =>
>        <= VALUE __version__  0 9\r\n1.2.0-rc1\r\nEND\r\n
>
> For something like stats, there should be a key whose value is all the stat
> keys recognized by that server.  Ie
>
>    get __stat_keys__\r\n =>
>        <= VALUE __stat_keys__ 0 329\r\n__pid__ __uptime__...\r\nEND\r\n
>
> One could then mget some or all stats:
>
>    get __pid__ __uptime__ __time__\r\n
>
> For multiparameter admin command like 'stats cachedump' some standard
> parameter delimiter syntax can  be used.  Ie
>
>    get __cachedump__?id&limit\r\n
>
> This could be done very efficiently on the server side.  Basically once the
> reserved prefix is identified, just tokenize the key and fork off to the
> existing stats/admin command handling functions.  They'd have to be tweaked
> somewhat for the new format.  The main thing would be to documents required
> and optional well-known keys in the protocol spec.
>
> I'm interested in prototyping this.  I wanted to get a sense of people's
> interest and if there are any obvious choices for a reserved-key
> prefix/suffix that won't conflict with current installations.
>
>