Oh, and I've shared the photos I've taken last night on Flickr too: http://www.flickr.com/photos/tmaesaka/sets/72157608050620544/
On Thu, Oct 16, 2008 at 12: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). > > 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. >> >
