<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">So you assume the two are separate,
Emmanuel. So do I.<br>
<br>
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 things simple for the
scope of the PoC. But let's not make this too simple because it
will stop being useful. My expectation is to see a generic yet
fully typed 'cache service' interface that does not depend on the
key and value types that come from userland, using maybe
'google.protobuf.Any' or our own 'WrappedMessage' type instead.
I'm not sure what to believe now because discussing my hopes and
assumptions on the gRPC topic on zulip I think I understood the
opposite is desired. Vittorio, please comment on this.<br>
<br>
I'm still hoping we want to keep the service interface generic and
separated from the user model. And if we do it, would you expect
to be able to marshall the service call using gRPC lib and at the
same time be able to marshall the user model using whatever other
library? Would be nice but that seems to be a no-no with gRPC, or
I did not search deep enough. I only looked at the java
implementation anyway. It seems to be forcing you to go with
protoc generated code and protobuf-java.jar all the way, for
marshalling both the service and its arguments. And this goes
infinitely deeper. If a service argument of type A has a nested
field of type B and the marshaller for A is generated with
protobuf-java then so is B. Using oneofs or type 'Any' still do
not save you from this. The only escape is to pretend the user
payload is of type 'bytes'. At that point you are left to do your
marshaling to and from bytes yourself. And you are also left with
the question, what the heck is the contents of that byte array
next time you unmarshall it, which is currently answered by
WrappedMessage. <br>
<br>
So the more I look at gRPC it seems elegant for most purposes but
lacking for ours. And again, as with protocol buffers, the wire
protocol and the IDL are really nice. It is the implementation
that is lacking, IMHO.<br>
<br>
I think to be really on the same page we should first make a clear
statement of what we intend to achieve here in a bit more detail.
Also, since this is not a clean slate effort, we should think
right from the start what are the expected interactions with
existing code base, like what are we willing to sacrifice.
Somebody mention hot rod please!<br>
<br>
Adrian<br>
<br>
<br>
On 05/29/2018 07:20 PM, Emmanuel Bernard wrote:<br>
</div>
<blockquote type="cite"
cite="mid:90D7A540-1A86-48F6-8986-484CD5CC8398@hibernate.org">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>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. </div>
<div><br>
On 29 May 2018, at 15:51, Sanne Grinovero <<a
href="mailto:sanne@infinispan.org" moz-do-not-send="true">sanne@infinispan.org</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 29 May 2018 at 13:45, Vittorio
Rigamonti <span dir="ltr"><<a
href="mailto:vrigamon@redhat.com" target="_blank"
moz-do-not-send="true">vrigamon@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>Thanks Adrian,<br>
<br>
</div>
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).<br>
<br>
</div>
<div>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.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div class="gmail_default" style="font-size:small">This
might indeed be reasonable for some developers, some
languages.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">Thanks,</div>
<div class="gmail_default" style="font-size:small">Sanne</div>
<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>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.<br>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, May 28, 2018 at
4:47 PM, Adrian Nistor <span dir="ltr"><<a
href="mailto:anistor@redhat.com"
target="_blank" moz-do-not-send="true">anistor@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div
class="m_4216121092935601651m_4400301142433856756moz-cite-prefix">Hi
Vittorio,<br>
thanks for exploring gRPC. It seems like
a very elegant solution for exposing
services. I'll have a look at your PoC
soon.<br>
<br>
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. <br>
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.<br>
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.<br>
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:)<br>
<br>
Adrian
<div>
<div class="m_4216121092935601651h5"><br>
<br>
On 05/28/2018 04:15 PM, Vittorio
Rigamonti wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="m_4216121092935601651h5">
<div dir="ltr">
<div>Hi Infinispan developers,<br>
<br>
</div>
<div>I'm working on a solution for
developers who need to access
Infinispan services through
different programming languages.<br>
</div>
<div><br>
The focus is not on developing a
full featured client, but rather
discover the value and the
limits of this approach.<br>
<div><br>
</div>
</div>
<div>- is it possible to
automatically generate useful
clients in different languages?<br>
</div>
<div>- can that clients
interoperate on the same cache
with the same data types?<br>
</div>
<div><br>
</div>
<span
id="m_4216121092935601651m_4400301142433856756m_-8148977098275501500gmail-result_box"
class="m_4216121092935601651m_4400301142433856756m_-8148977098275501500gmail-"
lang="en"><span
class="m_4216121092935601651m_4400301142433856756m_-8148977098275501500gmail-">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.</span></span><br>
<div><br>
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.<br>
</div>
<div><br>
Currently the project is nothing
more than a poc with the
following interesting features:<br>
<br>
</div>
<div>- client can be generated in
all the grpc supported language:
java, go, c++ examples are
provided;<br>
</div>
<div>- the interface is full
typed. No need for marshaller
and clients build in different
language can cooperate on the
same cache;<br>
</div>
<div><br>
</div>
<div>The second item is my
preferred one beacuse it frees
the developer from data
marshalling.<br>
<br>
</div>
<div>What do you think about?<br>
</div>
<div>Sounds interesting?<br>
</div>
<div>Can you see any flaw?<br>
</div>
<div><br>
There's also a list of issues
for the future [2], basically I
would like to investigate these
questions:<br>
How far this architecture can
go?<br>
Topology, events, queries... how
many of the Infinispan features
can be fit in a grpc
architecture?<br>
</div>
<div><br>
</div>
<div>Thank you<br>
</div>
<div>Vittorio<br>
</div>
<br>
[1] <a
href="https://github.com/rigazilla/ispn-grpc"
target="_blank"
moz-do-not-send="true">https://github.com/rigazilla/i<wbr>spn-grpc</a><br
clear="all">
<div>
<div>
<div>[2] <a
href="https://github.com/rigazilla/ispn-grpc/issues"
target="_blank"
moz-do-not-send="true">https://github.com/rigazilla/i<wbr>spn-grpc/issues</a><br
clear="all">
<br>
</div>
<div>-- <br>
<div
class="m_4216121092935601651m_4400301142433856756m_-8148977098275501500gmail-m_-8431198291286624134m_1982721755148179188gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<p
style="font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>Vittorio</span>
<span>Rigamonti</span></p>
<p
style="font-weight:normal;font-size:10px;margin:0px
0px
4px;text-transform:uppercase"><span>Senior
Software
Engineer</span></p>
<p
style="font-weight:normal;margin:0px;font-size:10px;color:rgb(153,153,153)"><a
style="color:rgb(0,136,206);font-size:10px;margin:0px;text-decoration:none;font-family:"overpass",sans-serif"
href="https://www.redhat.com" target="_blank" moz-do-not-send="true">Red
Hat <span><br>
<br>
</span></a></p>
<span
style="font-size:10px;margin:0px;color:rgb(153,153,153)">
<p
style="font-size:10px;margin:0px">Milan,
Italy</p>
</span>
<p
style="font-weight:normal;margin:0px
0px
6px;font-size:10px;color:rgb(153,153,153)"><span
style="margin:0px;padding:0px"> <a
style="color:rgb(0,136,206);font-size:10px;margin:0px;text-decoration:none;font-family:"overpass",sans-serif"
href="mailto:vrigamon@redhat.com" target="_blank" moz-do-not-send="true">vrigamon@redhat.com</a><br>
</span></p>
<p
style="font-weight:normal;margin:0px
0px
6px;font-size:10px;color:rgb(153,153,153)"><span
style="margin:0px;padding:0px">irc: rigazilla </span> </p>
<a
href="https://red.ht/sig"
target="_blank"
moz-do-not-send="true">
<img
src="https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red-hat-black.png"
moz-do-not-send="true" height="auto" width="90"></a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset
class="m_4216121092935601651m_4400301142433856756mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<pre>______________________________<wbr>_________________
infinispan-dev mailing list
<a class="m_4216121092935601651m_4400301142433856756moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org" target="_blank" moz-do-not-send="true">infinispan-dev@lists.jboss.org</a>
<a class="m_4216121092935601651m_4400301142433856756moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank" moz-do-not-send="true">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a></pre>
</blockquote>
<p><br>
</p>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div
class="m_4216121092935601651gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<p
style="font-weight:bold;margin:0;padding:0;font-size:14px;text-transform:uppercase;margin-bottom:0"><span>Vittorio</span>
<span>Rigamonti</span></p>
<p
style="font-weight:normal;font-size:10px;margin:0px
0px 4px;text-transform:uppercase"><span>Senior
Software Engineer</span></p>
<p
style="font-weight:normal;margin:0;font-size:10px;color:#999"><a
style="color:#0088ce;font-size:10px;margin:0;text-decoration:none;font-family:'overpass',sans-serif"
href="https://www.redhat.com"
target="_blank"
moz-do-not-send="true">Red Hat <span><br>
<br>
</span></a></p>
<span
style="font-size:10px;margin:0px;color:rgb(153,153,153)">
<p style="font-size:10px;margin:0">Milan,
Italy</p>
</span>
<p style="font-weight:normal;margin:0px
0px
6px;font-size:10px;color:rgb(153,153,153)"><span
style="margin:0px;padding:0px">
<a
style="color:#0088ce;font-size:10px;margin:0;text-decoration:none;font-family:'overpass',sans-serif"
href="mailto:vrigamon@redhat.com"
target="_blank"
moz-do-not-send="true">vrigamon@redhat.com</a><br>
</span></p>
<p style="font-weight:normal;margin:0px
0px
6px;font-size:10px;color:rgb(153,153,153)"><span
style="margin:0px;padding:0px">irc:
rigazilla </span>
</p>
<a href="https://red.ht/sig"
target="_blank" moz-do-not-send="true">
<img
src="https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red-hat-black.png"
moz-do-not-send="true" height="auto"
width="90"></a></div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org"
moz-do-not-send="true">infinispan-dev@lists.jboss.org</a><br>
<a
href="https://lists.jboss.org/mailman/listinfo/infinispan-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>infinispan-dev mailing list</span><br>
<span><a href="mailto:infinispan-dev@lists.jboss.org"
moz-do-not-send="true">infinispan-dev@lists.jboss.org</a></span><br>
<span><a
href="https://lists.jboss.org/mailman/listinfo/infinispan-dev"
moz-do-not-send="true">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></span></div>
</blockquote>
<!--'"--><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
infinispan-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></pre>
</blockquote>
<p><br>
</p>
</body>
</html>