Thanks Emmanuel, actually I started this thread just to describe what I did, I probably forgot an "An" at the beginning of the subject :)
Vittorio On Tue, May 29, 2018 at 6:20 PM, Emmanuel Bernard <emman...@hibernate.org> wrote: > Right. Here we are talking about a gRPC representation of the client > server interactions. Not the data schema stored in ISPN. In that model, the > API is compiled by us and handed over as a package. > > On 29 May 2018, at 15:51, Sanne Grinovero <sa...@infinispan.org> wrote: > > > > On 29 May 2018 at 13:45, Vittorio Rigamonti <vriga...@redhat.com> 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. >> > > This might indeed be reasonable for some developers, some languages. > > Just please make sure it's not the only option, as many other developers > will not expect to need a compiler at hand in various stages of the > application lifecycle. > > For example when deploying a JPA model into an appserver, or just booting > Hibernate in JavaSE as well, there is a strong expectation that we'll be > able - at runtime - to inspect the listed Java POJOs via reflection and > automatically generate whatever Infinispan will need. > > Perhaps a key differentiator is between invoking Infinispan APIs (RPC) vs > defining the object models and related CODECs for keys, values, streams and > query results? It might get a bit more fuzzy to differentiate them for > custom functions but I guess we can draw a line somewhere. > > Thanks, > Sanne > > > >> >> 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> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://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>
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev