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 <gosulli...@pivotal.io> wrote: > 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 > > > > > >
