[ 
https://issues.apache.org/jira/browse/THRIFT-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644747#comment-13644747
 ] 

Carl Yeksigian commented on THRIFT-1948:
----------------------------------------

The current list requires the knowledge of the number of items a priori. This 
would allow the elements to be written as they are read.

Also, the allowance for streams to be interleaved, as well as server/clients to 
have open streams at the same time, would allow easier two way communications.
                
> 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

Reply via email to