Support multiple parameters for rpc functions

[Marvin Somebody]

Hello,

recently I started using protobuf for one of my projects, as I finished with defining my services I tried to compile but it didn't worked. That was because I defined my functions like at {2} , I did this because for me as programmer it is normal that functions can be defined with more than one parameter. In my opinion protobuf should support it because it improves readably and if I can omit the messages to encapsulate others so the codebase will be  also smaller.

message User {
    required bytes uuid = 1;
    required string name = 2;
}


message ChatMessage {
    required User sender = 1;
    required string msg = 2;
}


message StatusResponse {
    required int32 status = 1;
}


//That's what I currently do {1}
message MessageTransfer {
    required User recipient = 1;
    required ChatMessage msg = 2;
}


service ChatService {
    rpc sendmessage(MessageTransfer) returns (StatusResponse);
}


//That's what I want to do {2}
service ChatService {
    rpc sendmessage(ChatMessage msg ,User recipient) returns (StatusResponse);
}

Thanks for reading

[Feng Xiao]

We have discussed this feature request before and the decision is that we won't support it. To achieve what you need, you can define a new message type with all the parameters you need as fields and use this message as the request type.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[Marvin Somebody]

Can you tell me what's the reason for your decision? 

[Feng Xiao]

On Tue, Aug 26, 2014 at 2:35 AM, Marvin Somebody <h0nswu...@gmail.com> wrote:

Can you tell me what's the reason for your decision? 

We decided against it because such a feature will complicate proto syntax, API and implementation without bring any true value.

[Pratap Koritala]

One parameter method works fine if we start with proto and define the services.

But, most of the code is usually evolved, For ex: Existing distributed java services, who wants to use protobuf,  instead of RMI/java-Serialization. This feature is very useful in doing that.