Issue 258 in protobuf: Allow service methods with 0 arguments and/or no return value

[prot...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 258 by mike.wel...@gmail.com: Allow service methods with 0
arguments and/or no return value
http://code.google.com/p/protobuf/issues/detail?id=258

I'm implementing a cross-network messaging system and trying to use the
proto service section to tell my plugin about what 'methods' it should
generate code for.

This 'system' consists of named objects which can send messages to one
another. However there are no return values. You send a message to a named
object, that object receives it, and if it wants to send something back in
response it has to send a separate message back to the original sender.

So it's not RPC really, just a way of asynchronously sending messages to
named objects on a network.

It would be useful if the proto compiler or services section would allow
for a more general definition of messages/methods and arguments. At the
moment the compiler requires a return statement and one argument.

Would there be a problem with allowing an empty/void return value and empty
argument list? In my proof-of-concept I have created an empty message
called 'void' and used that for the argument/return value where necessary
to stop the compiler from complaining. But that's obviously a hack and
leads to additional code being generated for the 'void' message.

As a more concrete example, let's say I have a multiplayer tic-tac-toe game
and one message that can be sent is RequestGame. There are no arguments to
this message and no return value. An object simply sends a reponse back
accepting or rejecting the offer. What I would like to write in this case
it:

rpc KeepAlive() returns ();

or just

rpc KeepAlive();

Would this be something you would consider supporting? If not, is there any
way to extend the .proto language so I can add my own services-like section
and syntax or should I just develop my own DSL for these purposes?

[prot...@googlecode.com]

Comment #1 on issue 258 by mike.wel...@gmail.com: Allow service methods

with 0 arguments and/or no return value
http://code.google.com/p/protobuf/issues/detail?id=258

Sorry the example rpc lines should read:

---

rpc RequestGame() returns ();

or just

rpc RequestGame();

---

I updated my example but not the code.

[prot...@googlecode.com]

Comment #2 on issue 258 by ev...@mit.edu: Allow service methods with 0

arguments and/or no return value
http://code.google.com/p/protobuf/issues/detail?id=258

I seem to recall that the argument here may be "this is as designed." The
typical "work around" is that you define an empty argument / return value
and use that. The argument is that this is typically a better design, since
then you can evolve your application: when you discover that you *do* need
to pass some options around, or have some return value, you just extend the
empty message.

I'm not the official word on this stuff though.

[prot...@googlecode.com]

Updates:
Status: WontFix

Comment #3 on issue 258 by jas...@google.com: Allow service methods with 0

arguments and/or no return value
http://code.google.com/p/protobuf/issues/detail?id=258

Yes, as Evan said, we have found that these types of service definitions
don't hold up over time. Your KeepAlive() example makes a better case for
it than RequestGame(), which sounds like it actually should return a
response. KeepAlive() may actually never need a request or response;
receiving the RPC specifies the action enough. These use cases are
typically rare though, and the cost of using an empty message is small
compared to the hassle that you may face down the road. Supporting this
would also add complications to the RpcController interface and/or RPC
implementations.

If you are concerned about code size, you can try setting optimize_for =
CODE_SIZE. For an empty message, the performance difference is probably
going to be negligible to the application.