[
https://issues.apache.org/jira/browse/THRIFT-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646045#comment-13646045
]
Carl Yeksigian commented on THRIFT-1948:
----------------------------------------
Precisely.
I think there are a couple of benefits to the stream approach versus having
many calls.
# Client to know how many times to call back to the server
# State does not need to be sent, or regenerated for each call
I also think the use case isn't very well defined in the ticket. I'll put
together something a little better defined for the use of this new construct.
> Add a stream type
> -----------------
>
> Key: THRIFT-1948
> URL: https://issues.apache.org/jira/browse/THRIFT-1948
> Project: Thrift
> Issue Type: New Feature
> Components: AS3 - Compiler, AS3 - Library, C glib - Compiler, C glib
> - Library, C# - Compiler, C# - Library, C++ - Compiler, C++ - Library, Cocoa
> - Compiler, Cocoa - Library, Compiler (General), D - Compiler, D - Library,
> Delphi - Compiler, Delphi - Library, Erlang - Compiler, Erlang - Library, Go
> - Compiler, Go - Library, Haskell - Compiler, Haskell - Library, Java -
> Compiler, Java - Library, JavaME - Compiler, JavaME - Library, JavaScript -
> Compiler, JavaScript - Library, Node.js - Compiler, Node.js - Library, OCaml
> - Compiler, OCaml - Library, Perl - Compiler, Perl - Library, PHP - Compiler,
> PHP - Library, Python - Compiler, Python - Library, Ruby - Compiler, Ruby -
> Library, Smalltalk - Compiler, Smalltalk - Library
> Reporter: Carl Yeksigian
> Assignee: Carl Yeksigian
>
> This is a proposal for an addition to the Thrift IDL, which allows for
> sending chunks of data between the server and the client without having the
> whole message in memory at the start of the communication.
> The new keyword, "stream<T>", would indicate that there is a series of values
> typed T which would be communicated between client and server. Stream would
> have three primitives:
> {code}
> next(T)
> error(TException)
> end()
> {code}
> Protocols would be enhanced with the following methods:
> {code}
> writeStreamBegin(etype, streamid)
> writeStreamNext(streamid, streamMessageType)
> writeStreamNextEnd()
> writeStreamErrorEnd()
> etype, streamid = readStreamBegin()
> streamid, streamMessageType = readStreamNext()
> readStreamNextEnd()
> readStreamErrorEnd()
> {code}
> streamMessageType is one of the following:
> # next
> This means that the message will be of the element type.
> # error
> An exception was thrown during materialization of the stream.
> The stream is now closed.
> # end
> This means that the stream is finished.
> The stream is now closed.
> Once all streams are closed, readMessageEnd should be called. Before the
> first writeStreamNext() could be called, the message should otherwise be
> complete. Otherwise, an exception should be raised.
> It is possible that an exception will be thrown while the stream is being
> materialized; however, this can only occur inside of a service. In this case,
> error() will be called; the exception should be one of the exceptions that
> the service call would have thrown. The values that were generated before the
> exception will generally be valid, but may only have meaning if the stream is
> ended. All streams which are currently open may get the same exception.
> If the following service was defined:
> {code}
> stream<i64> random_numbers(stream<i64> max)
> {code}
> A sample session from client to server would be:
> {code}
> writeMessageBegin()
> writeStreamBegin(I64, 0)
> writeStreamNext(0, next)
> writeI64(10)
> writeStreamNextEnd()
> writeStreamNext(0, end)
> writeMessageEnd()
> {code}
> A sample session from server to client would be:
> {code}
> writeMessageBegin()
> writeStreamBegin(i64, 0)
> writeStreamNext(0, next)
> writeI64(3)
> writeStreamNextEnd()
> writeStreamNext(0, end)
> writeMessageEnd()
> {code}
> This change would not be compatible with previous versions of Thrift. Also,
> for languages which do not support this type of streaming, it could be
> translated into a list.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
