Next Major Memcached release / roadmap?

[McFarlane Josh - jmcfar]

You can already easily do this with your keys, just format the keys in the form of "project1::key", "project2::key", etc.

Another option is to launch multiple instances on different ports on the server, and have one project connect to one set of ports, and another project to the another port.

Josh McFarlane


-----Original Message-----
From: memcached-bounces at lists.danga.com on behalf of André Cruz
Sent: Wed 5/30/2007 11:29 AM
To: memcached at lists.danga.com
Subject: Re: Next Major Memcached release / roadmap?
 
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        ||||| | | | |  |  |  |   |   |
> lindner at inuus.com

*************************************************************************
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be
legally privileged.

If the reader of this message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank you.
*************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070618/5ba6d9fd/attachment.htm