Next Major Memcached release / roadmap?

[Marc]

The main thing I¹d like to see fixed in memcached is the wire protocol.  I¹d
like to see the ASCII protocol rationalized and an additional binary
protocol.

These changes are motivated two goals.  Efficient protocol message
processing (ie the message processor should never have to look at a
character of a message more than once) and recovery of data from large UDP
multigets.

For ASCII rationalization I'd like to see the following:
    
    All replies should be of the form ³<reply-id><header>[\r\n<data>]?\r\n²
        Spefically that means incr/decr would return something like:
        incr 12345\r\n not 12345\r\n as is done now.

    Error messages should have a similar format to get replies
    ³<error>|<client_error>|<server_error> <len>\r\n<error message\r\n²

    It would really be helpful if we could proscribe the sequence Œ\r\n¹
    from values, stats, and error message.
    Keeping Œ\r\n¹ out of values means that the client could resynch if
    packets are lost in a large UDP multiget.  This doesn't require any
    change on the server side, but must be enforced by all compliant
    clients.  (ie escape \r\n on add/set/replace and unescape on get)

The binary protocol would be pretty straight forward.

As I mentioned in an earlier post, I¹d like to eliminate commands like stat,
version, and a few others in favor of exposing those things as well-known
keys in a reserved part of the key namespace.  So rather than rationalizing
the stats command, just make it a 'get __stats__' get request.

Protocol migration can be handled by reserved keys ³__protocol_version__²
and ³__protocol_modes__².  The former would just be a version identifier.
The latter, a bitmap with 1 for ASCII and 2 for BINARY, &c.  Next major
release would support versions 1 & 2 of the protocol and both ASCII and
BINARY.  The release after that could drop version 1.  I think we'll always
want to have support for ASCII.
    
On 6/16/07 10:15 AM, "Jose Celestino" <japc at co.sapo.pt> wrote:

> Words by Marcus Rueckert [Sat, Jun 16, 2007 at 05:10:36PM +0200]:
>> On 2007-05-30 17:29:44 +0100, André Cruz wrote:
>>> 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...
>> 
>> how about using "context:realkey" as key for your memcached operations.
>> and voila you can working with different namespaces on the same memcached.
>> 
> 
> Yes. We do that already for a SMTP throttling cache, SEEN::IP,
> BLOCKED::IP, GREYED::IP :)