I am wondering why we are leaning so heavily toward RPC IDL rather than messaging standards.
One of the big features of the client-server discussion around Geode is the ability to register interest and run Continuous Queries. Both of these behave more like messaging than RPCs. Beyond that all that Geode really does is puts and gets and function calls. A put is analogous to a publish. A get is similar to a subscribe. A function call can be implemented as a put on a special topic that has a callback attached to it. In fact that's how we used to do server side functions before we added the function execution api. The other thing we are constantly battling with is being able to push more and more data into Geode from clients faster and faster. That too lends itself to a messaging protocol. In fact, I remember that last year we were already having some discussions about maybe developing a client based on MQTT. That would make GemFire a natural for the Internet-of-Things and for mobile devices. I wonder if it would be sufficient for a full-blown .Net GemFire client. One of our goals in this thread is to be able to have clients in many languages. Well, there are at least 75 different language bindings for MQTT already out in the wild. MQTT is agnostic about what format the payload is in, so we could support PDX if we choose to, or ProtoBufs or FlatBuffers or whatever else for payload serialization. Thoughts? -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: +1-631-835-4771 On Mon, Apr 10, 2017 at 2:39 PM, Galen M O'Sullivan <gosulli...@pivotal.io> wrote: > On Mon, Apr 10, 2017 at 10:47 AM, Bruce Schuchardt <bschucha...@pivotal.io > > > wrote: > > > I agree that key/value serialization is a separate issue and more related > > to storage than communications. The thing I'm struggling with is how to > > specify message metadata in an RPC IDL. I'm thinking of things like an > > eventID, transaction info, security principal, etc. The basic > > client/server messaging doesn't need to know the details of this > > information - just that it exists and maybe the ID of each piece of > > metadata. > > > > Is there any reason that this data couldn't be packed into, say, Thrift > types? It's all numbers, right? >
