[ https://issues.apache.org/jira/browse/AVRO-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16553553#comment-16553553 ]
Srujan Narkedamalli edited comment on AVRO-2187 at 7/24/18 8:49 AM: -------------------------------------------------------------------- If we are using boolean property on the message, it is actually indicating only whether the response is streaming type or not. So we could have this property as "reponseStreaming". I think the info regarding request streaming should also be a message level boolean property ("requestStreaming") rather than field in protocol request to avoid confusion . was (Author: srujann): If we are using only boolean property on the message i think it would actually indicate only whether the response is streamed. So we could have this property as "reponseStreaming". I think the info regarding request streaming should also be a message level property ("requestStreaming") rather than in protocol request to avoid confusion . > Add RPC Streaming constructs/keywords to Avro IDL or schema > ----------------------------------------------------------- > > Key: AVRO-2187 > URL: https://issues.apache.org/jira/browse/AVRO-2187 > Project: Avro > Issue Type: New Feature > Reporter: Srujan Narkedamalli > Priority: Major > > Motivation: > We recently added support for transporting Avro serialization and IDL over > gRPC for Java. In order to use the streaming features of gRPC or any other > transport that supports streaming we need to be able to specify them IDL and > schema. > Details: > Currently, gRPC supports 3 types of streaming calls: > # server streaming (server can send multiple responses for a single request) > # client streaming (client can multiple requests and server sends a single > response) > # bi-directional streaming call (on going rpc with multiple requests and > responses) > We would want a way to represent these types on calls in Avro's IDL similar > to one-way calls using a keywords. Usually in gRPC with other IDLs a > streaming request or response is repeated payload of same type. For client > streaming and bi-directional streaming it would be simpler to have a single > request argument when representing their type in callbacks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)