missing binary protocol details
Dustin Sallings
dustin at spy.net
Sun Jul 22 08:38:01 UTC 2007
I was just finishing up some of my test binary protocol
implementation and wanted to make sure we actually finish up the
definition. I've got an implementation of the core functionality I
believe we need in both server and client, but there are a few areas
I'm not sure how to deal with.
Firstly, I've just made up all the constants I didn't steal from the
client Paul Querna wrote and said not to steal from:
http://hg.west.spy.net/hg/python/memcached-test/file/tip/
memcacheConstants.py
Obviously that's all easy to change, but I couldn't do much testing
without at least some values.
I implemented delete by key only. The ascii protocol supports a
delay operation that affects add and replace. Is this used
anywhere? Should we add a packet format for it?
Get returns the flags as a four-byte big-endian integer as part of
the response. The responses aren't defined in the current doc, so I
assumed this was desirable.
incr and decr are a little...special. How is this stored on the
server? Do we return integer typed data or ascii representations?
Would it make sense to define it to receive a default value and just
pass integers back and forth over the wire?
I implemented a no-arg flush. I'm not sure whether we wanted to
retain flush's argument (delay before flush processing begins) as
it's caused confusion. At least it's confused me. Not a huge deal
either way.
If anyone else is writing a binary protocol server or client, let me
know if my test code is helpful so far.
http://hg.west.spy.net/hg/python/memcached-test/
--
Dustin Sallings
More information about the memcached
mailing list