On Oct 17, 5:04 am, "Henrik Schröder" <[EMAIL PROTECTED]> wrote:
> To the rest of the people on this list, don't you think it'd be a good idea > to get some standardization going for the flags with the release of the > binary protocol? The actively supported clients will make implementation > changes for it, and there will be new clients made for languages that have > no actively supported client, so there will be a lot of implementation going > on, and if we can standardize the flags, we can get everyone on the same > page, which would be pretty nice. It comes up quite a bit. > The minimum thing would be a flag for unmodified byte-arrays. If everyone > agrees on a flag value for that, we technically get full client > interoperability because users can then build custom serialization on top of > that. I don't think that provides a lot of value over just allowing more flexible transcoding mechanisms. If it's just byte arrays, it seems like that'd put a burden on the users to pack more info into the data since the flags would be unavailable. > To make life a bit easier we should have a standard flag value for > UTF8-encoded strings, and maybe also define a flag value for string-encoded > numbers, the ones that the incr and decr commands work on. Yes, standard flags would be good. Someone had put together a table of flags observed in the wild. I'm not sure if this is the latest: http://www.hjp.at/zettel/m/memcached_flags.rxml Convergence would be good. > Finally, JSON objects for data structures like arrays and associative arrays > of strings and numbers. Yeah, that's good for the most simple things. > I checked the latest version of the Binary protocol spec > athttp://code.sixapart.com/svn/memcached/branches/binary/server/doc/pro... > it mentions "Data Type (reserved for future use)". Well. How about we > define it now? It still feels like a bad idea, and it's not stored anywhere. It's in there because there was space and someone really, really wanted it. The idea is that flags will be available for user applications, but clients will be able to have their own set of flags that client users don't get access to. Just sounds rather messy to me. I'd want to expose them all because I *still* think users should be able to define their own encoding formats for their own applications.
