<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Fair point. That's why protobuf's Any
has a type url inside, exactly for such flexibility :
<a class="moz-txt-link-freetext" href="https://github.com/google/protobuf/blob/master/src/google/protobuf/any.proto#L150">https://github.com/google/protobuf/blob/master/src/google/protobuf/any.proto#L150</a><br>
Well, it's not a mime-type as per infinspan but close enough.<br>
<br>
On 05/30/2018 01:22 PM, Gustavo Fernandes wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAH8Ud1Hs_5D6nAp9MGGC_-4X6HCWbCx3sx3BB74JXH0hA8AQ0w@mail.gmail.com">
<div dir="ltr"><br>
<div class="gmail_extra">On Wed, May 30, 2018 at 10:56 AM,
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>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_-1046137647920781934moz-cite-prefix">The
oneof and WrappedMessage solve the same problem but in
a different way.<br>
Oneof has the nasty effect that in ties the service
model to the user data model. </div>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>The user data model is only "static" at storage level
(guided by configuration), and the user data can travel on
the wire in any format the user wants [1]<br>
</div>
<div><br>
</div>
<div>[1] <a
href="https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/test/java/org/infinispan/client/hotrod/transcoding/DataFormatTest.java#L109"
moz-do-not-send="true">https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/test/java/org/infinispan/client/hotrod/transcoding/DataFormatTest.java#L109</a><br>
</div>
<div><br>
</div>
<div>So better not to assume it will be marshalled and
unmarshalled in a specific way.<br>
</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_-1046137647920781934moz-cite-prefix">Even
if it seems like just one more line of code to add
when a new user type is introduced, it is one line of
code in the wrong place because you'll have to
re-generate the service. IE user run protoc again on
OUR IDLs. Should a user do that? This coupling between
the infinispan's service model and the user's data
model bothers me. <br>
<br>
WrappedMessage is just a wrapper around an array of
bytes + information regarding what message type or
what scalar type is in there. Something very similar
to a VARIANT [1]. The reason it is needed is explained
here [2].<br>
<br>
You are correct, this is not a gRPC limitation, it is
a by-design protobuf protocol limitation, that was
very thoughtfully introduced to reduce wire level
bandwitdth for the common case where types are static.
Unfortunately it leaves generic/dynamic types in
mid-air. But it is fairly easy to solve, as you can
see with WrappedMessage. At the time I introduced
WrappedMessage we were using protobuf 2.<br>
<br>
protobuf 3 introduces type Any, which solves the issue
in a similar way with WrappedMessage. The difference
is Any seems to have been created to wrap either a
plain byte[] or a message type that has been
marshalled to a byte[]. No support for scalars in
sight. Can we solve that? Sure, put a WrappedMessage
inside that byte[] :)))) That is the reason I did not
jump immediately at using Any and stayed with
WrappedMessage.<br>
<br>
Can a 150 lines PoC be a proposal for the ISPN object
model? No, but we need to explore the pain points of
gRPC and protobuf that are relevant to our usage, and
this thing with genericly typed services is one of
them.<br>
I think we already have a good solution in sight,
before giving up and going with byte[] for key and
value as it was suggested earlier here. I can make a
PR to the grpc PoC to show it by the end of the week.<br>
<br>
Adrian<br>
<br>
[1] <a
class="gmail-m_-1046137647920781934moz-txt-link-freetext"
href="https://en.wikipedia.org/wiki/Variant_type"
target="_blank" moz-do-not-send="true">https://en.wikipedia.org/wiki/<wbr>Variant_type</a><br>
[2] <a
class="gmail-m_-1046137647920781934moz-txt-link-freetext"
href="https://developers.google.com/protocol-buffers/docs/techniques#streaming"
target="_blank" moz-do-not-send="true">https://developers.google.com/<wbr>protocol-buffers/docs/<wbr>techniques#streaming</a>
<div>
<div class="gmail-h5"><br>
<br>
On 05/30/2018 11:34 AM, Vittorio Rigamonti wrote:<br>
</div>
</div>
</div>
<div>
<div class="gmail-h5">
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, May 29, 2018
at 8:59 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:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div
class="gmail-m_-1046137647920781934m_-7719467217180458836moz-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>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yep that was my design choice. Well my
first goal was to keep the framework
language independent: to reach that I
tried to define in grpc/protobuf as much
as possible (that's why I didn't use the
Any clause). Then I realized that with
very little effort I could design a
framework that works only with user data
from the user side to the cache storage
and I'd liked to investigate this, manly
for two reasons:<br>
<br>
</div>
<div>- from the user point of view I like
the idea that I can found my objects types
in the cache<br>
</div>
<div>- the
embeddedCache<object,object> is
transparently exposed<br>
<br>
</div>
<div>but this is my 150 lines of code grpc
server prototype, not a proposal for the
ISPN object model. However it's ok to use
it as starting point for a wider
discussion<br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div
class="gmail-m_-1046137647920781934m_-7719467217180458836moz-cite-prefix">
<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>
</div>
</div>
</blockquote>
<div> </div>
<div>And indeed the "oneof" clause in my
message definition solves the same problem
solved by the WrappedMessage message: what
I have to do with these bytes? Actually
I'm not sure this is a gRPC limitation: if
I receive a stream of bytes I also need
some info on what I have to
reconstruct.... I'm just guessing<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div
class="gmail-m_-1046137647920781934m_-7719467217180458836moz-cite-prefix">
<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!<span
class="gmail-m_-1046137647920781934HOEnZb"><font
color="#888888"><br>
<br>
Adrian</font></span>
<div>
<div
class="gmail-m_-1046137647920781934h5"><br>
<br>
<br>
On 05/29/2018 07:20 PM, Emmanuel
Bernard wrote:<br>
</div>
</div>
</div>
<div>
<div
class="gmail-m_-1046137647920781934h5">
<blockquote type="cite">
<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"
target="_blank"
moz-do-not-send="true">sanne@infinispan.org</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div 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:0px 0px
0px
0.8ex;border-left:1px
solid
rgb(204,204,204);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
style="font-size:small">This
might indeed be
reasonable for some
developers, some
languages.</div>
<div
style="font-size:small"><br>
</div>
<div
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
style="font-size:small"><br>
</div>
<div
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
style="font-size:small"><br>
</div>
<div
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
style="font-size:small"><br>
</div>
<div
style="font-size:small">Thanks,</div>
<div
style="font-size:small">Sanne</div>
<br>
</div>
<div> </div>
<blockquote
class="gmail_quote"
style="margin:0px 0px
0px
0.8ex;border-left:1px
solid
rgb(204,204,204);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="gmail-m_-1046137647920781934m_-7719467217180458836HOEnZb">
<div
class="gmail-m_-1046137647920781934m_-7719467217180458836h5">
<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:0px 0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div
bgcolor="#FFFFFF">
<div
class="gmail-m_-1046137647920781934m_-7719467217180458836m_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="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651h5"><br>
<br>
On 05/28/2018
04:15 PM,
Vittorio
Rigamonti
wrote:<br>
</div>
</div>
</div>
<blockquote
type="cite">
<div>
<div
class="gmail-m_-1046137647920781934m_-7719467217180458836m_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="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651m_4400301142433856756m_-8148977098275501500gmail-result_box"
class="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651m_4400301142433856756m_-8148977098275501500gmail-"
lang="en"><span
class="gmail-m_-1046137647920781934m_-7719467217180458836m_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="gmail-m_-1046137647920781934m_-7719467217180458836m_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="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651m_4400301142433856756mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<pre>______________________________<wbr>_________________
infinispan-dev mailing list
<a class="gmail-m_-1046137647920781934m_-7719467217180458836m_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="gmail-m_-1046137647920781934m_-7719467217180458836m_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="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651gmail_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>
<br>
______________________________<wbr>_________________<br>
infinispan-dev mailing
list<br>
<a
href="mailto:infinispan-dev@lists.jboss.org"
target="_blank"
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/mailma<wbr>n/listinfo/infinispan-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>______________________________<wbr>_________________</span><br>
<span>infinispan-dev mailing
list</span><br>
<span><a
href="mailto:infinispan-dev@lists.jboss.org"
target="_blank"
moz-do-not-send="true">infinispan-dev@lists.jboss.org</a></span><br>
<span><a
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></span></div>
</blockquote>
<br>
<fieldset
class="gmail-m_-1046137647920781934m_-7719467217180458836mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
infinispan-dev mailing list
<a class="gmail-m_-1046137647920781934m_-7719467217180458836moz-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="gmail-m_-1046137647920781934m_-7719467217180458836moz-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>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div
class="gmail-m_-1046137647920781934gmail_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>
</blockquote>
<p><br>
</p>
</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>
<!--'"--><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>