On Tue, May 29, 2018 at 8:49 PM, Adrian Nistor <anis...@redhat.com> wrote:
> Vittorio, a few remarks regarding your statement "...The alternative to > this is to develop a protostream equivalent for each supported language and > it doesn't seem really feasible to me." > > No way! That's a big misunderstanding. We do not need to re-implement the > protostream library in C/C++/C# or any new supported language. > Protostream is just for Java and it is compatible with Google's protobuf > lib we already use in the other clients. We can continue using Google's > protobuf lib for these clients, with or without gRPC. > this is a solution that we could explore > Protostream does not handle protobuf services as gRPC does, but we can add > support for that with little effort. > > The real problem here is if we want to replace our hot rod invocation > protocol with gRPC to save on the effort of implementing and maintaining > hot rod in all those clients. I wonder why the obvious question is being > avoided in this thread. > > Adrian > > > On 05/29/2018 03:45 PM, Vittorio Rigamonti wrote: > > Thanks Adrian, > > of course there's a marshalling work under the cover and that is reflected > into the generated code (specially the accessor methods generated from the > oneof clause). > > My opinion is that on the client side this could be accepted, as long as > the API are well defined and documented: application developer can build an > adhoc decorator on the top if needed. The alternative to this is to develop > a protostream equivalent for each supported language and it doesn't seem > really feasible to me. > > On the server side (java only) the situation is different: protobuf is > optimized for streaming not for storing so probably a Protostream layer is > needed. > > On Mon, May 28, 2018 at 4:47 PM, Adrian Nistor <anis...@redhat.com> wrote: > >> Hi Vittorio, >> thanks for exploring gRPC. It seems like a very elegant solution for >> exposing services. I'll have a look at your PoC soon. >> >> I feel there are some remarks that need to be made regarding gRPC. gRPC >> is just some nice cheesy topping on top of protobuf. Google's >> implementation of protobuf, to be more precise. >> It does not need handwritten marshallers, but the 'No need for >> marshaller' does not accurately describe it. Marshallers are needed and are >> generated under the cover by the library and so are the data objects and >> you are unfortunately forced to use them. That's both the good news and the >> bad news:) The whole thing looks very promising and friendly for many uses >> cases, especially for demos and PoCs :))). Nobody wants to write those >> marshallers. But it starts to become a nuisance if you want to use your own >> data objects. >> There is also the ugliness and excessive memory footprint of the >> generated code, which is the reason Infinispan did not adopt the >> protobuf-java library although it did adopt protobuf as an encoding format. >> The Protostream library was created as an alternative implementation to >> solve the aforementioned problems with the generated code. It solves this >> by letting the user provide their own data objects. And for the marshallers >> it gives you two options: a) write the marshaller yourself (hated), b) >> annotated your data objects and the marshaller gets generated (loved). >> Protostream does not currently support service definitions right now but >> this is something I started to investigate recently after Galder asked me >> if I think it's doable. I think I'll only find out after I do it:) >> >> Adrian >> >> >> On 05/28/2018 04:15 PM, Vittorio Rigamonti wrote: >> >> Hi Infinispan developers, >> >> I'm working on a solution for developers who need to access Infinispan >> services through different programming languages. >> >> The focus is not on developing a full featured client, but rather >> discover the value and the limits of this approach. >> >> - is it possible to automatically generate useful clients in different >> languages? >> - can that clients interoperate on the same cache with the same data >> types? >> >> I came out with a small prototype that I would like to submit to you and >> on which I would like to gather your impressions. >> >> You can found the project here [1]: is a gRPC-based client/server >> architecture for Infinispan based on and EmbeddedCache, with very few >> features exposed atm. >> >> Currently the project is nothing more than a poc with the following >> interesting features: >> >> - client can be generated in all the grpc supported language: java, go, >> c++ examples are provided; >> - the interface is full typed. No need for marshaller and clients build >> in different language can cooperate on the same cache; >> >> The second item is my preferred one beacuse it frees the developer from >> data marshalling. >> >> What do you think about? >> Sounds interesting? >> Can you see any flaw? >> >> There's also a list of issues for the future [2], basically I would like >> to investigate these questions: >> How far this architecture can go? >> Topology, events, queries... how many of the Infinispan features can be >> fit in a grpc architecture? >> >> Thank you >> Vittorio >> >> [1] https://github.com/rigazilla/ispn-grpc >> [2] https://github.com/rigazilla/ispn-grpc/issues >> >> -- >> >> Vittorio Rigamonti >> >> Senior Software Engineer >> >> Red Hat >> >> <https://www.redhat.com> >> >> Milan, Italy >> >> vriga...@redhat.com >> >> irc: rigazilla >> <https://red.ht/sig> >> >> >> _______________________________________________ >> infinispan-dev mailing >> listinfinispan-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> > > > -- > > Vittorio Rigamonti > > Senior Software Engineer > > Red Hat > > <https://www.redhat.com> > > Milan, Italy > > vriga...@redhat.com > > irc: rigazilla > <https://red.ht/sig> > > > -- Vittorio Rigamonti Senior Software Engineer Red Hat <https://www.redhat.com> Milan, Italy vriga...@redhat.com irc: rigazilla <https://red.ht/sig>
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev