Thrift doesn't support this directly. Thrift supports streaming in the sense that structures can be serialized on the fly -- sending data over the wire can be done directly through an object's write method, rather than serializing the object to a byte array first and then sending it over the wire. Basically, the serialization process is linear -- later elements in a struct never influence serialization of prior elements.
The application-layer Thrift code doesn't currently support access to streaming below the struct layer, because the provided read() methods on structs are self-contained. Lists/sets/maps in Thrift also have fixed sizes which are sent over the wire -- this makes *sending* a stream with unknown length a priori impossible, though it doesn't prevent creation of a *receiving* iterator (in fact, the iterator could be quite smart is it would know the difference between not having any more elements to read vs. not having received all the data *yet*). Application code certainly could be written with Thrift that gives an iterator to struct elements coming over the wire -- but admittedly the design is not as naturally oriented towards doing so. If this is something lots of people would find useful I think it'd be worth building -- though I've always felt that list/map/set is more convenient and tends to represent the "common case" for repeated fields. -----Original Message----- From: Vicaya [mailto:[EMAIL PROTECTED] On Behalf Of Luke Lu Sent: Tuesday, July 08, 2008 2:07 PM To: [email protected] Subject: Re: protocol buffers open sourced Does thrift protocol support the "repeateds" field mentioned in the protobuf doc? This is very handy for implementing streaming/scanning efficiently. According to the thrift paper, the thrift encoding itself is designed to support streaming. But it seems that the thrift language is not expressive enough to support it. list/set/map just doesn't cut it (you can't do anything with it until they're fully instantiated). The repeated field can be naturally translated into an iterator/enumerator interface in native languages. __Luke On Jul 8, 2008, at 7:24 AM, Chad Walters wrote: > Looking over Google's documentation, it doesn't appear that there is > much in Protocol Buffers that we don't offer and obviously Thrift does > a lot more than PB. > > Probably the place where we suffer the most in comparison is > documentation. I intend to spend some time soon (this weekend?) > throwing up more documentation on the Wiki. Once I get that done, I'd > love some folks to look it over, give comments, and refine it. > > Chad > > On 7/7/08 3:32 PM, "Jeff Hammerbacher" <[EMAIL PROTECTED]> > wrote: > > pretty interesting: > http://google-code-updates.blogspot.com/2008/07/protocol-buffers-our-s > erialized.html > . > no mention of stubby... > >
