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).
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. The solution is to pass the engine a pointer to the connection structure with the callback. The engine itself does not temper with this pointer at all. All it does is, it feed the pointer to the callback function, meaning the engine does not have to understand the connection structure. Once the pointer is passed to the callback, the callback understands the structure since it lives inside the core server. So in this context, this pointer acts as a cookie and heres what we can benefit from it: - 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. As for the client stuff, Jonathan went through and reviewed my binary protocol patch for Cache::Memcached and found that some assumptions I made in the code can be improved (protocol negotiation related). He is also looking at optimizing the code for us by subclassing the patch (reduces the number of conditional selections and hash lookups). So the Perl folks will hopefully be able to enjoy the binary protocol in no time :) 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. Thats all I can remember for now but I'll post to this thread if I remember anything else :) Cheers, Toru On Wed, Oct 15, 2008 at 5:48 PM, Dustin <[EMAIL PROTECTED]> wrote: > > The hackathon went well again. Admittedly, I didn't talk to everyone > there, but from the corner with the food, there was some additional > protocol work and tree merging going on. Please fill in interesting > things that happened that I didn't know about or forgot. > > In particular, Toru implemented stats for the binary protocol. It's > pretty good stuff. I wrote java client support for it, and helped > iron out some minor issues that arose. > > I think the only change that came out of this was that the opaque > behavior was kind of undefined. All opaque values coming out of stats > were set to 0 (and the requested opaque was ignored). Stats values > will have the magic opaque value of 0x746f7275 and the terminating > stat will have the requested opaque value. > > > *INCOMPATIBILITY NOTES* > > We have one change coming up that has been affecting me a lot re: > compatibility and that's the removal of hold values from delete. If > you rely on this behavior, please let someone know -- it's going away. > > Brad did some work on making the long parser more strict in incr/ > decr. If you rely on arbitrary objects being treated as 0, you have a > silent bug that will turn into a loud bug in the future. >
