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
over that overhead
* it can introduce backward compatibility issues that we have no control
over
* it won't fit into our configuration and management infrastructure
However, I do like the idea of exploring the use of other serialization
software if it has good multi-language support.
Le 4/10/2017 à 1:38 PM, Michael William Dodge a écrit :
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?
