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. > >
