Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

I don't like the idea of using someone else's messaging software for several reasons: * we may have needs that are beyond its capabilities * it may impose something like a broker or endpoint IDs that we have to deal with * it introduces more overhead per message and we will have no control

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

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

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

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

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

On Mon, Apr 10, 2017 at 10:47 AM, Bruce Schuchardt 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

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

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

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

I have used plenty of RPC protocols that pass raw binary as input/output values because the types are not pre defined. All the frameworks mentioned support byte arrays. -Jake On Mon, Apr 10, 2017 at 10:36 AM Galen M O'Sullivan wrote: > Hi Jacob, > > The message protocol

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

Hi Jacob, The message protocol is conflated with user data serialization in pretty much all of these frameworks I've seen. If we define some RPC in Thrift, we have to specify the type of data that gets passed to the call. The type of that data is specified using the Thrift IDL, meaning it's a

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

You are confusing message protocol with user data serialization. The two are not related. Look at HTTP, the message protocol is pretty simple, PUT, GET, etc., but it does nothing with the data being PUT/GET. On a GET the message protocol has a field that specifies the Content-Type and

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

> On Apr 7, 2017, at 3:11 PM, Galen M O'Sullivan wrote: > > I think the main selling point of an RPC framework/IDL is ease-of-use for > defined remote communications that look like function calls. If you have > calls you're making to remote servers asking them to do work,

Why we shouldn't use RPC Frameworks for the New Geode Protocol

I think the main selling point of an RPC framework/IDL is ease-of-use for defined remote communications that look like function calls. If you have calls you're making to remote servers asking them to do work, you can fairly trivially define the interface and then call through. You can then use