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 Thrift-serialized object. We could have all the remote procedure calls take and return byte arrays, but then I'm not sure what the benefit of using Thrift is.
The nice thing about HTTP is that it's specified what it looks like on the wire and there's a defined mechanism for negotiating content type. The RPC frameworks I've seen aren't as clearly specified[1]. We would also have to write our own mechanism for negotiating encoding. It seems to me like we would be doing more work than we would be gaining. Another factor that will also constrain our serialization choices as well as RPC frameworks is that a lot of serialization libraries expect all the types to be known as runtime. We currently allow users to serialize POJOs or anything that will fit in PDX, and we want to keep that capability. [1]: I think I could reconstruct BERT based on the Erlang docs, but Thrift is harder. gRPC is basically Protobuf-encoded data over HTTP/2. We could put binary data in protobufs, but I'd rather not. On Fri, Apr 7, 2017 at 5:23 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > 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-Encoding and some other metadata. So the GET could get HTML, JPEG, > etc. but the protocol doesn't care and doesn't know anything special about > that type of the data it puts. The structure for JPEG is not defined in the > HTTP protocol at all. > > So relate that to what we want to do. Our message protocol defines a PUT > and a GET operation, some metadata perhaps and a section for the data. It > should have no restriction or care on how that data was serialized. The > protocol does not define in any way the structure of the data being PUT or > GET. > > Separating that concern then, does your argument still stand that PRC > frameworks do not work for the new Geode protocol? > > On Fri, Apr 7, 2017 at 3:11 PM Galen M O'Sullivan <gosulli...@pivotal.io> > 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 trivially define the interface and then call through. You can then > > use native types in function calls and they transparently get transformed > > and sent across the wire. > > > > The RPC protocols I've seen are based on the idea that the types that can > > be sent will be predefined -- otherwise it's hard to describe with an > IDL. > > > > However, we want to support storing unstructured data, or at least data > > structures that are defined (from the cluster's point of view) at runtime > > -- one of the main selling points of Geode is PDX serialization, which > lets > > us store arbitrary object structures in the cache. If we were to use an > RPC > > framework we have all the commands accept byte arrays and include some > > meta-information. This loses us the ease-of-use. > > > > What's left in the protocol then is the calls and the number of arguments > > they accept, and what order we put those (and the serialized arguments) > in > > on the wire. I don't think we gain much by using a preexisting RPC > > language, and we lose control over the wire format and message structure. > > If we want to be able to make the protocol really fast, and customized to > > our use case; if we want to implement asynchronous requests, futures, > etc. > > then we have to write wrappers for a given language anyways, and packing > > those things through an RPC framework like Thrift or gRPC will be an > extra > > layer of confusing complexity. > > > > Best, > > Galen > > >
