Lets just make sure that whatever we settle on will allow us to have the flexibility to add and remove fields from our messages in case we find out we left something important out.
Lots of binary protocols over the years have been extremely inflexible in this regard. -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: +1-631-835-4771 On Mon, Apr 3, 2017 at 11:24 AM, Galen O'Sullivan (JIRA) <j...@apache.org> wrote: > Galen O'Sullivan created GEODE-2746: > --------------------------------------- > > Summary: Investigate and Evaluate Existing RPC frameworks. > Key: GEODE-2746 > URL: https://issues.apache.org/jira/browse/GEODE-2746 > Project: Geode > Issue Type: Sub-task > Reporter: Galen O'Sullivan > > > There are several existing RPC frameworks for which you can define the > structure of your protocol and the tool will generate code for talking over > the wire, generally down to serialization of objects. > > If one of those RPC frameworks does not fit all our requirements, we'll > design our own binary protocol. This protocol would define both what kind > of messages can be sent and how they are encoded on the wire. How we encode > the objects that we are sending in requests, however, could still be > pluggable. > > A few contenders: > * [BERT|http://bert-rpc.org] > * [thrift|https://thrift.apache.org/] > * [gRPC|http://www.grpc.io/] > > This is one half of GEODE-2734. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.15#6346) >
