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 >
