Tim Bunce wrote: > On Fri, Jan 11, 2008 at 05:07:10PM +0300, Tomash Brechko wrote: >> On Fri, Jan 11, 2008 at 16:54:26 +0300, Tomash Brechko wrote: >>> I'd love to coordinate F_COMPRESSED flag. C::M and C::M::F currently >>> use 0x2 (0x1 is F_STORABLE). >> Thinking more about this, perhaps we may do the following. As I >> understand most client libraries do not export flags to the user, but >> use them internally for bookkeeping. There are 16/32 (which one?) > > 16 bits, per > http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt > > <flags> is an arbitrary 16-bit unsigned integer (written out in > decimal) that the server stores along with the data and sends back > when the item is retrieved. Clients may use this as a bit field to > store data-specific information; this field is opaque to the server. > Note that in memcached 1.2.1 and higher, flags may be 32-bits, instead > of 16, but you might want to restrict yourself to 16 bits for > compatibility with older versions. > > I wonder why that says "may". Does anyone know? > > If it is now 32-bit then we'd know that the top 16 bits are very > unlikely to be used at the moment and so we could adopt those > for "informal standardisation" with little risk. >
Flags are passed around as a signed 32-bit value internally. Which is vs a normal unsigned 32-bit value. We can change the protocol.txt to say it's 32-bit, but only as of 1.2.1, and to test it with your client first? Cookies to someone who adds a test for 32-bit flags into the server :) I don't suspect there are any issues with the value being signed internally. Thoughts? -Dormando
