I like the idea of efficient support for union's as it would allow me to use Thrift as a traditional game network protocol where the server and client just send "messages" (which would be any struct defined to be in your Client2Server protocol and Server2ClientProtocol). The Client2Server union would define messages client send to the server, and the Server2Client defines what the server sends to client.
The Client2Server union is very similiar to RPC service definitions, the biggest difference is the Server2Client protocol I'd want it to be like a "reverse RPC" that the server would initiate sending messages to a connected client transport (the server response message to the client would not have to be directly related to any client sent request or RPC). I worked with a closed-source message protocol IDL system in C++/Java similiar to Thrift and the way we'd do this is define the structs like you do in Thrift and additionally each struct is given an Message ID and each language is given a lookup table so when they receive a msg they're given it's ID and it's size. The input/output transport for client and server would work the same, they'd read a message Type and size off the network then read in the struct defined by that message ID. I think the concept of "messages" is similiar to how Thrift implements RPC services the trouble is I can't seem to find support to allow a serevr respond to a connected client unless that client initiates an RPC call and then it would only be able to respond with the particular defined response type (which could be made to be "anything" if you use the Union message as a response), but still that doesn't allow the server to initiate a message to the client, the client would have to poll for messages, also the trouble with Unions is it feels like you're repeating yourself (but I guess you do need some way to indicate which messages are Client2Server and which are Server2Client) On Thu, Mar 26, 2009 at 6:57 AM, mark weisser <[email protected]>wrote: > maybe the solution is to create the C++ code and then the thrift code > > Bryan Duxbury wrote: > > Hey all, > > > > I wanted to propose an idea I've been toying around with for a little > > while. At Rapleaf, we've developed a sort of pattern for creating > > Thrift objects that are all of the same type, but by convention only > > contain one of many fields. That is, every one of our objects has two > > required fields and ~80 optional fields, of which only one is ever > > set. This gives us union-like functionality, so our object could > > conceivably be of any one the many subtypes. One of the two required > > fields is an i32 that contains the Thrift field id of the field that > > should be set. > > > > There are a lot of things that are good about this approach: it's > > simple, it's pretty sparse on the wire, and its very flexible. > > However, there are some things about it that aren't so great: nothing > > in Thrift validates the relationship between the field type specifier > > field and the data field or guarantees only one of the data fields is > > set. We've been able to work around these limitations for the most > > part, but it's been something we've had to deal with at the > > application level. Another limitation is that the cpu impact > > attempting to serialize 79 unset fields seems to be as much as 100% > > overhead to serialization performance. > > > > What I would really like is for Thrift to support this behavior > > natively. I was thinking that we could add a "union" construct to > > Thrift, which would exist parallel to "struct". In some languages, > > this could potentially map to an actual union; in languages like Java > > and Ruby, we'd probably have to make some sort of TUnion class to > > mimic the behavior. I don't think we'd need a new wire type or > > anything. All of the behavior changes would be in the generated code, > > making sure that it didn't read two values for the same union field, etc. > > > > What do people think about this idea? If we like it we can start to > > flesh it out some more and then open a ticket to get implementations > > going. > > > > -Bryan > > ------------------------------------------------------------------------ > > > > > > No virus found in this incoming message. > > Checked by AVG - www.avg.com > > Version: 8.0.238 / Virus Database: 270.11.28/2022 - Release Date: > 03/25/09 07:16:00 > > > > > >
