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: [EMAIL PROTECTED] on behalf of André Cruz Sent: Wed 5/30/2007 11:29 AM To: [email protected] 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 ||||| | | | | | | | | | > [EMAIL PROTECTED] ************************************************************************* 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. *************************************************************************
