MQTT is an interesting idea but from the wiki page it sounds like it depends on a broker. In that architecture, would the server be the broker as well as a publisher and subscriber? Would the locator be the broker? Or would we introduce a separate broker, either third-party or bespoke?
Sarge > On 10 Apr, 2017, at 13:21, Michael Stolz <mst...@pivotal.io> wrote: > > 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? >>
