Next Major Memcached release / roadmap?

[Randy Wigginton]

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        ||||| | | | |  |  |  |   |   |
> lindner at inuus.com