[
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)