How about different caches on the same memcache servers? We would
like to have a pool of several memcache servers and use them for all
our projects. Each project accessing memcache would supply a
"context" with the memcache operations so that key collisions didn't
happen between projects..
Just a thought...
André
On 2007/05/30, at 12:47, 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]
