Dispatch on (service, procedure, encoding)

[HelloGrayson]

We need to decide whether or not to dispatch on the triple of (service, procedure, encoding) or not. Currently, we route on (service, procedure), and if the encoding is not correct, it will fail to serialize/deserialize.

Are there any benefits to routing on the full triple instead?

cc @yarpc/golang

[prashantv]

In a far off future world, it'd be great if the same handler code could be used for different encodings transparently (e.g. you can make this request over Thrift or Protobuf, and the same handler logic is used to generate a response).

However, unless we have a good use case, I don't think we should expose dispatching to different handlers based on the Encoding -- that seems confusing. E.g. if a user could implement their own Meta::health for JSON that returned a completely different result that the Thrift Meta::health method.

I think disallowing registration on the triplet also leaves us room in the future to add the feature if there are good use cases.

[HelloGrayson]

@abhinav @kriskowal what do you guys think?

[abhinav]

I buy Prashant's argument. We can add this later without breaking anything, but we can't remove it once added. We'll need to validate the encodings in the handlers though. I think we have a TODO for that right now.

[HelloGrayson]

We should at least determine whether or not this field should be required or not - currently it's optional.

[prashantv]

+1 to required

[HelloGrayson]

Will close this for now in favor of #238