Cross-client memcached compatibility

dormando dormando at
Sat Feb 2 09:50:58 UTC 2008

Ciaran wrote:
>     It will not (native format is unpredictable, so you can't judge from
>     some first magic bytes), but I think this is not a problem.  If the
>     goal would be to simultaneously support some clients that use only
>     native format, and some that use common, this would be no different
>     from requesting to support interaction with clients each using its own
>     format, and we are back to encoding used serialization method in
>     flags.
>     If you want interaction among several clients, the requirement should
>     be to use the same serialization technique, no exceptions.  If all
>     clients are from the same language family, you may use native,
>     otherwise you have to use common.
> I wholeheartedly agree :)
> - Ciaran

Well, for the second point, obviously? Yes? All I was proposing was a
way to grandfather the current interfaces. Instead of forcing people
into a new callback system if they decide to upgrade their client.

For the first point; I don't understand why you'd want to arbitrarily
limit serialization. If I write a gigantic web application which uses
native serialization, and add a single experimental web service that
pulls from a particular data stream, we should be afforded options. They
don't even have to agree on anything other than "This ain't native, you
ought to know better if you're asking for the key. But me, the client,
certainly won't attempt to deserialize this for you".


More information about the memcached mailing list