On Jun 1, 2008, at 9:12, Henrik Schröder wrote:
(Oh okay, it doesn't support the UDP protocol, but... who does?)
Well, Brian supports it. I haven't had a need for it myself yet,
though.
Sounds reasonable, it's pretty evident that CAS is an afterthought
with the separate gets and cas commands.
New commands were mainly to keep existing clients happy.
I actually wondered about the reason for the binary protocol, I
would guess that the difference in parsing variable-length text
strings and fixed-length byte arrays is totally negligible compared
to network latency, but I guess it makes it easier to add things
like CAS to everything. :-)
The binary protocol is a lot easier to work with both in servers and
clients, and certainly less work to ``parse.'' The cas-on-everything
wasn't added until the fourth revision, though.
Yes, it's pretty sad actually that it hasn't caught on very well in
the Windows world. Sadly, I'm not a (good) C programmer, so I can't
help. At my company we're pretty concerned about the bad performance
of the Windows port of the memcached server, it affects our website
Nonoba, so we might end up investing some resource sin getting it to
work better, but I really can't promise anything. It's definitely in
our interest to have a good working version of the server for
Windows though, so we'll see. I suspect that the problems are
related to the Windows port of libevent, and that might be pretty
tricky to track down, and not something I would want to do with my
meager C skills. :-)
There are lots of ways to help. Simply ensuring it builds is a good
start. I wouldn't even know how to go about compiling a C program in
Windows if I had a place to do it. :)
--
Dustin Sallings
