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
ove
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
>
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 tha
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 things like an
> eventID, tra
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
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 is conflated with user d
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
Thri
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
Content-Encod
> 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, you can
> fairly trivia
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 nati
10 matches
Mail list logo
