RPC

[msoucy]

RPC support is not currently functional, but the code is started.

[Downchuck]

Seems like this should follow gRPC, perhaps as a different package.

[msoucy]

gRPC seems to use proto3 by default, which until now I didn't know had existed (real life got on the way)

Either way, proto2 still needs to support generating stubs for RPC... I don't actually know much about it, and have no time to learn about it currently (though I wish I did), but if you or someone else does, feel free to make a pull request

[Downchuck]

I'd like to see support for generating the interfaces, but not actual RPC.

I've had a similar experience using Avro in a Java project -- they have an RPC protocol, but I only needed to use it for interface generation. Adding in actual RPC means prescribing an underlying networking library and additional protocols. At minimum it means additional boilerplate in the interface.

There's a somewhat decent example here in the C++ docs: https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#service

service Foo {
  rpc Bar(FooRequest) returns(FooResponse);
}

Turns into this, when generating service stubs:

virtual void Bar(RpcController* controller, const FooRequest* request,
                 FooResponse* response, Closure* done);

An abstract method that simply calls:

controller->SetFailed()

That async pattern is certainly nice when it's hooked up to RPC, but for simple interface generation, it seems messy.

[Downchuck]

Is there a good method to set options for the template?

"ProtocolBufferFromString" is just fine, but I'm looking at the possibility of options such as defaulting to proto3 (or some kind of non-strict mode) and the option of generating an interface as sync vs. async for service methods.

For my taste, I'd just have non-strict and sync, for that grpc example:

message HelloRequest {
  string greeting = 1;
}

message HelloResponse {
  string reply = 1;
}

service HelloService {
  rpc SayHello(HelloRequest) returns (HelloResponse);
}

[msoucy]

Not currently, unfortunately...if you have ideas I'm open.

[Downchuck]

Looks like the standard is just to create more names, though parameters are fairly easy to pass. So we may have ProtocolBuffersAsync, ProtocolBuffersImpl, etc.

Async generating classes looking like (RPCContext, input..., output..., Callback), Impl generating sync classes that simply return stubs, and the default returning a simple interface. I did not find any examples of returns() returning more than one argument, in the wild, thankfully.

[msoucy]

I'm thinking arguments would be more convenient...

[Downchuck]

I think we have appropriate support now for Proto2 and this issue can be closed. We do not have full support for Proto3 semantics.

[msoucy]

Sounds good to me!