inconsistent identifier capitalization between protoc-gen-go and protoc-gen-grpc-gateway

[palohan]

In the following proto file, notice the underscores, numbers (and possibly other characters) in identifiers:

syntax = "proto3";
import "google/api/annotations.proto";
package template;

service Greeter {
  rpc Sen_dGet (Temp_lateRequest) returns (template_response) {
      option (google.api.http).get = "/get";
  }
  rpc SendGe2t (Temp_lateRequest) returns (template_response) {
      option (google.api.http).get = "/get";
  }
}

message Temp_lateRequest {
  string name = 1;
}

message template_response {
  string name = 1;
}

After compiling such file, building the executables produces these errors:

../template/template.pb.gw.go:36:15: undefined: Temp_lateRequest
../template/template.pb.gw.go:43:20: client.Sen_dGet undefined (type GreeterClient has no field or method Sen_dGet)
../template/template.pb.gw.go:53:15: undefined: Temp_lateRequest
../template/template.pb.gw.go:60:20: client.SendGe2t undefined (type GreeterClient has no field or method SendGe2t, but does have SendGe2T)

Looking at the pb.go file, we can see the identifiers are different from those in pb.gw.go file

type GreeterClient interface {
	SenDGet(ctx context.Context, in *TempLateRequest, opts ...grpc.CallOption) (*TemplateResponse, error)
	SendGe2T(ctx context.Context, in *TempLateRequest, opts ...grpc.CallOption) (*TemplateResponse, error)
}

Judging from the code, this happens because protoc-gen-go uses CamelCase

./grpc/grpc.go:159:	servName := generator.CamelCase(origServName)
./grpc/grpc.go:283:	methName := generator.CamelCase(origMethName)

whereas protoc-gen-grpc-gateway simply calls strings.Title

./protoc-gen-grpc-gateway/gengateway/template.go:85:		svcName := strings.Title(*svc.Name)
./protoc-gen-grpc-gateway/gengateway/template.go:89:			methName := strings.Title(*meth.Name)

[johanbrandhorst]

I think the easiest fix here will be copy-pasting the protoc-gen-go generator logic into the generator, but it is problematic since long term they will inevitably deviate. This here is another source of incompatibility with protoc-gen-gogo as well since the latter allows a custom name to be used. I wish we could have some way of reading from the file we use but I don't think it's possible.

This should be reasonably easy to fix, anyway.

[waveywaves]

@johanbrandhorst I am starting work on this issue. Do let me know if there is something I need to keep in mind.

[johanbrandhorst]

@waveywaves thanks! I don't think there's anything particular to keep in mind if we can easily port the logic from protoc-gen-go.