generalized redis format

[kr]

Hi, I just wanted to get your opinion on this... We're using a generalized form of the redis protocol format in doozer, and I thought it would be neat to split out the protocol parsing code into a standalone library.

Of course redis.go is already out there and I don't want to step on your toes. In fact, we would have just used redis.go except that it's a little too specific to the actual redis server.

Here's the code we're using:
https://github.com/bmizerany/doozer/blob/master/src/pkg/proto/proto.go

https://github.com/bmizerany/doozer/blob/master/src/pkg/proto/fit.go

And we're consuming this code in our client and server packages:
https://github.com/bmizerany/doozer/tree/master/src/pkg/client

https://github.com/bmizerany/doozer/tree/master/src/pkg/server

What would you think of providing a lower-level interface similar to this in redis.go? I'm primarily referring to functions encode, decode, and Fit in the code linked above. Or, alternatively, pulling the formatting code into a separate package that we could both share in redis.go and doozer?

There are two things here that I'm fond of.

First is generalization of the format -- a "multi-bulk" response can contain any data: "bulk" data, integers, even other multi-bulk data recursively. Also, we don't treat requests or responses specially -- the full format can be used and parsed in either direction. This is useless when talking to the redis server, but handy when designing a new server-client pair that wants to use the redis format (as in the case of doozer).

Second is an interface similar to the json and gob packages, where the user can provide a pointer to any object and get it filled in by incoming data. But the code for that is pretty involved and it only makes sense if the library is intended to be general-purpose and used by many people. If we wind up not sharing any code after all, we'll likely rip out that feature and replace it with a few simple special-case functions.

If you're amenable to the idea, I'll be happy to redo these thoughts in the form of patches to redis.go (or a separate package) so we can have a more concrete discussion about it.