We first defined a pair of interfaces to describe the functionality of the existing wire format, one for the client, and one for the server (depicted below).
type ServerCodec interface {
ReadRequestHeader(*Request) os.Error
ReadRequestBody(interface{}) os.Error
WriteResponse(*Response, interface{}) os.Error
Close() os.Error
}On the server side, we then changed two internal function signatures to accept the ServerCodec interface instead of our existing gob.Encoder. Here's one of them:
func sendResponse(sending *sync.Mutex, req *Request,
reply interface{}, enc *gob.Encoder, errmsg string)became
func sendResponse(sending *sync.Mutex, req *Request,
reply interface{}, enc ServerCodec, errmsg string)We then wrote a trivial gobServerCodec wrapper to reproduce the original functionality. From there it is simple to build a jsonServerCodec.
After some similar changes to the client side, this was the full extent of the work we needed to do on the RPC package. This whole exercise took about 20 minutes! After tidying up and testing the new code, the final changeset was submitted.
In an inheritance-oriented language like Java or C++, the obvious path would be to generalize the RPC class, and create JsonRPC and GobRPC subclasses. However, this approach becomes tricky if you want to make a further generalization orthogonal to that hierarchy. (For example, if you were to implement an alternate RPC standard.) In our Go package, we took a route that is both conceptually simpler and requires less code be written or changed.
A vital quality for any codebase is maintainability. As needs change, it is essential to adapt your code easily and cleanly, lest it become unwieldy to work with. We believe Go's lightweight, composition-oriented type system provides a means of structuring code that scales.
