So you assume the two are separate, Emmanuel. So do I.
But in the current PoC the user data model is directly referenced by the
service model interface (KeyMsg and ValueMsg are oneofs listing all
possible user application types???). I was assuming this hard dependency
was there just to make
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#
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 wrote:
>
>
>
>> On 29 May 2018 at 13:45, Vittorio
On 29 May 2018 at 13:45, 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
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:
Hi Galder,
**JDK 11 EA build 15 , *under both the GPL and Oracle EA licenses,
is now available at **http://jdk.java.net/11**. **
*
* Newly approved Schedule, status & features
o http://openjdk.java.net/projects/jdk/11/
* Release Notes:
o http://jdk.java.net/11/release-notes
*
FYI, I've also been looking into gRPC, as a tool to provide a (JGroups)
version-independent service that all traffic is sent to and received
from during a rolling cluster upgrade [1].
The focus of this is *version independence*, ie. have 3.6 and 4.x nodes
talk to each other. A non-requirement
Hi all,
@Vittorio, thanks a lot for working on this!
Let me explain some of the background behind this effort so that we're all
on the same page:
The biggest problem I see in our client/server architecture is the ability
to quickly deliver features/APIs across multiple language clients. Both
