In my opinion it would be very helpful to expect and support custom
extensions to memcache, in a manner that is maintainable between
releases. In our case, everything I've added is in a separate file,
so that when the next memcache version comes out, I just need to add
the file to the make and invoke my "continued command handler" from
inside of memcache's command handler.
Just as an aside, one of the extensions I've created is an
"aggregate" command. The format is:
AGGR <key> <value>
Then, I have entries in memcache that tracks the total, min, and max,
as well as count, of the key. Then later I can retrieve the key,
find the max, min, and average of the key. I've found it very useful
for operational purposes, someone else might too, but it probably
doesn't make sense as a core feature in memcache.
On May 30, 2007, at 4:47 AM, Paul Lindner wrote:
I've been thinking of where memcached is now and where it might go in
the future. I was hoping the community could come together and define
a roadmap of possible features to be added/incorporated in future
memcached releases.
Some patches that are floating around and are not yet committed
include:
* non-expiring entries patch from Paul G
* Ring buffers patch from Nathan.
* Append data to existing entry from Filipe
Also I have tasked myself with integrating some of Hi5's custom server
code into memcached. This code would include variants of the
memcached storage architecture and some possible background worker
threads.
Open issues that need consensus:
* Protocol changes -- do we want to extend memcached protocol to
support new features? If so, what is the logical way to do this.
* "Magic" values? Do we want to allow some kind of mapping of
client data to variations in server behavior?
For example the non-expiration patch allows you to configure a
value that results in a non-expiring item.
Others have proposed that special features be enabled for a common
prefix -- say all keys that have a "ringbuffer:" prefix use that
code path / storage engine..
* How do we accomodate new features without affecting performance.
* More? I'm sure there is..
Hopefully this gets things going. I hope we can agree on the right
approach so we can incorporate as many community contributions as is
possible and feasible.
--
Paul Lindner ||||| | | | | | | | | |
[EMAIL PROTECTED]
