On Oct 15, 8:53 am, "Toru Maesaka" <[EMAIL PROTECTED]> wrote: > Hi, > > About the opaque issue in the stats implementation, as much as I love > the 0x746f7275 idea (it would be funny) > Trond came up with a very flexible solution that looks like the way to > go (this happened at like 1am).
There goes your chance to be famous. > So, as far as the binary protocol spec goes, the server should really > send back what the client had supplied as opaque (rather than a magic > number), using a magic number would mean making an exception in the > protocol which is not so nice. OK, that's fine. In the meantime, my client will take any of the three values we've seen and/or discussed. I'll undo that at some point. > - We don't have to make an exception in the protocol. > - Since we are using a pointer, we can change the structure to > anything in the future. It does sound good. Also, note that the issues I was having with my deletion tests were because the hold was dropped so the server was refusing my hold request. All that's happy and I merged your binprot tree onto my binary tree. I actually would like to rewrite that branch for cleanliness. There are six different Tronds, two Torus, etc... I'd like to keep submissions a bit cleaner before they go upstream if possible. > Some client-side replication work was also being done for libmemcahed > as well I think. I remember Brian mentioning that they got a lot done > last night. I still haven't looked at client-side replication. It's one of those things that seems wrong, but people ask for it anyway. Thanks to Matt/Sun for hosting it and everybody else for showing up.
