metaget ascii protocol updates

[dormando]

Yo! I'm poking around for actively development memcached clients looking for some feedback for ASCII protocol changes in the server. Yeah I'm spamming a bit but I believe pretty strongly in these changes :)

memcached/memcached#484 - I've been developing on this for a while. I'm personally happy with the general approach and the code is at the 90% mark. What I'd love to hear now is some feedback from client authors/maintainers on how good/bad/annoying this would be to implement.

I can clear up/rewrite text/add examples if it's not clear enough right now. The protocol is low level, and I'd expect a raw-ish interface from clients. Most users will only be needing a couple of high level patterns, which should be easy to implement wrapping the raw protocol (a herd-protected get, stale-while-revalidate, etc). I haven't written these examples up explicitly yet while I look for feedback.

Thanks!

[jparise]

@dormando: I gave this a quick once-over, and nothing stands out as particularly difficult to support. I think we'd start with a raw 1-to-1 protocol interface (which is how we expose nearly all of the memcached commands already) and consider adding higher-level constructs later on.

I don't think I saw any cases where a client would have to actively parse the new commands and behave differently based on the passed flags, but I may have missed them. If there are cases like that, could you call them out explicitly?

Also, are there any particular guidelines on how clients should "detect" whether these new commands are available, and how it should behave when they aren't? Or should we just behave as we do today with regard to non-existent commands.

[dormando]

@jparise That sounds good. Just need to mind parsing the response codes is a bit different from a normal ASCII command.

I'm not too familiar with your client (looks like no binary protocol?), but the opaque may need some handling. Largely metaget is similar to noreply semantics, except the 'noreply' means 'no uninteresting responses' similar to binary protocol, rather than "eat everything and ruin your evening" of ASCII noreply. So you might need some memory to match up responses to requests depending on how the client is architected. I'll give it another read-over to ensure there aren't other special cases. Will respond again and update the original post if I find anything.

No detection guidance. Historically new commands are just added as we go along and nobody's complained. If they don't exist you'll get a standard error.

[dormando]

Fwiw, out in a tarball under 1.5.19, along with a lot more thorough documentation and a bunch of cleanups (doc/protocol.txt and a wiki page linked from there). Might still be some changes based on... well your feedback while implementing :)

I don't think there's anything different the client needs to do based on what comes back, but they need to pass the returned flags and tokens back up to the user so they can decide what to do with the response.