Clint Webb wrote: > I wasn't expecting such a quick reply. Good point about allowing > multiple protocols. I might pull out some of my old code and see how > easy it is to drop in. >
Cool :) I think we'd like to see how fast this ends up being, and how well it's worked into a client. I'll drop some caveats though: - We discussed the original binary protocol primarily as a method of simplifying the client, as well as being able to scale the number of commands in the server without using an if/else tree anymore (turn it into a switch/callback instead). So the goals were simplification, and speed. - We had a few ideas floating on making a "fully flexible" protocol but decided due to the former requirements we'd have to land somewhere in the middle. The binary protocol as is does allow command packing, but the header got kinda lengthy after the last hackathon. So if you wanted to do a set, then add some tags, you'd still do something like: setcmd tagcmd tagcmd ... in a single packet from the client (if the key is short enough). The binary protocol also implicitly allows something like noreply by simply adding more tiny commands. It'd be cool to have all three. I just hope you guys intend on benchmarking the damn things so we know what to recommend to client authors/users :) I care about theory far less than I care about shit working. -Dormando
