[infinispan-dev] Moving functional API to core

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] Moving functional API to core

Radim Vansa
Hi guys,

when the functional API has been outline, the interfaces were put into
infinispan-commons to make it possible to share these between remote
clients and embedded use case. However, it seems that reusing this as-is
impossible or at least impractical as we cannot send the lambdas in a
language neutral way. In the future, we may implement a way to share
functions between client and a server but that will most likely result
in an interface accepting something else than Function<ReadWriteEntry,
R>. Also, it's rather weird to have two EntryVersion interfaces.

Therefore I suggest moving org.infinispan.commons.api.functional to
infinispan-core, package org.infinispan.api.functional

You might say that the server-side code would use the interfaces, but
once it's running on server, it should depend on core (or core-api) -
commons is what is shared with the client, and if the client will in
future register a new function on the server, the user code should
depend on core-api as well (client-hotrod itself does not have to).

If you wonder what led me to this is that I've tried to add
SerializableFunction overloads to the FunctionalMap and found out that
SerializableFunction et all are only in infinispan-core (for good).

Please let me know if you have objections/if there something I have missed.

Radim

--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Moving functional API to core

Galder Zamarreño
Sounds good to me.

Remember that functional API is marked as experimental, so it's fine to do things like this.

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 9 Jun 2017, at 23:02, Radim Vansa <[hidden email]> wrote:
>
> Hi guys,
>
> when the functional API has been outline, the interfaces were put into
> infinispan-commons to make it possible to share these between remote
> clients and embedded use case. However, it seems that reusing this as-is
> impossible or at least impractical as we cannot send the lambdas in a
> language neutral way. In the future, we may implement a way to share
> functions between client and a server but that will most likely result
> in an interface accepting something else than Function<ReadWriteEntry,
> R>. Also, it's rather weird to have two EntryVersion interfaces.
>
> Therefore I suggest moving org.infinispan.commons.api.functional to
> infinispan-core, package org.infinispan.api.functional
>
> You might say that the server-side code would use the interfaces, but
> once it's running on server, it should depend on core (or core-api) -
> commons is what is shared with the client, and if the client will in
> future register a new function on the server, the user code should
> depend on core-api as well (client-hotrod itself does not have to).
>
> If you wonder what led me to this is that I've tried to add
> SerializableFunction overloads to the FunctionalMap and found out that
> SerializableFunction et all are only in infinispan-core (for good).
>
> Please let me know if you have objections/if there something I have missed.
>
> Radim
>
> --
> Radim Vansa <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Moving functional API to core

Dan Berindei
In reply to this post by Radim Vansa
+1

On Sat, Jun 10, 2017 at 12:02 AM, Radim Vansa <[hidden email]> wrote:

> Hi guys,
>
> when the functional API has been outline, the interfaces were put into
> infinispan-commons to make it possible to share these between remote
> clients and embedded use case. However, it seems that reusing this as-is
> impossible or at least impractical as we cannot send the lambdas in a
> language neutral way. In the future, we may implement a way to share
> functions between client and a server but that will most likely result
> in an interface accepting something else than Function<ReadWriteEntry,
> R>. Also, it's rather weird to have two EntryVersion interfaces.
>
> Therefore I suggest moving org.infinispan.commons.api.functional to
> infinispan-core, package org.infinispan.api.functional
>
> You might say that the server-side code would use the interfaces, but
> once it's running on server, it should depend on core (or core-api) -
> commons is what is shared with the client, and if the client will in
> future register a new function on the server, the user code should
> depend on core-api as well (client-hotrod itself does not have to).
>
> If you wonder what led me to this is that I've tried to add
> SerializableFunction overloads to the FunctionalMap and found out that
> SerializableFunction et all are only in infinispan-core (for good).
>
> Please let me know if you have objections/if there something I have missed.
>
> Radim
>
> --
> Radim Vansa <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Moving functional API to core

William Burns-3
In reply to this post by Radim Vansa


On Sat, Jun 10, 2017 at 12:56 AM Radim Vansa <[hidden email]> wrote:
Hi guys,

when the functional API has been outline, the interfaces were put into
infinispan-commons to make it possible to share these between remote
clients and embedded use case. However, it seems that reusing this as-is
impossible or at least impractical as we cannot send the lambdas in a
language neutral way. In the future, we may implement a way to share
functions between client and a server but that will most likely result
in an interface accepting something else than Function<ReadWriteEntry,
R>. Also, it's rather weird to have two EntryVersion interfaces.

Therefore I suggest moving org.infinispan.commons.api.functional to
infinispan-core, package org.infinispan.api.functional

You might say that the server-side code would use the interfaces, but
once it's running on server, it should depend on core (or core-api) -
commons is what is shared with the client, and if the client will in
future register a new function on the server, the user code should
depend on core-api as well (client-hotrod itself does not have to).

If you wonder what led me to this is that I've tried to add
SerializableFunction overloads to the FunctionalMap and found out that
SerializableFunction et all are only in infinispan-core (for good).

We could move these into commons in a major version if we need to as well. I never thought about using them in the client code as we never planned on supporting serialized lambdas there, but if it makes other things easier I am for it.

Also there is nothing stopping us from having these in commons right now, there is nothing special about the interfaces, they can just be copied over.
 

Please let me know if you have objections/if there something I have missed.

Radim

--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Moving functional API to core

Vittorio Rigamonti
In reply to this post by Radim Vansa
+1

On Fri, Jun 9, 2017 at 11:02 PM, Radim Vansa <[hidden email]> wrote:
Hi guys,

when the functional API has been outline, the interfaces were put into
infinispan-commons to make it possible to share these between remote
clients and embedded use case. However, it seems that reusing this as-is
impossible or at least impractical as we cannot send the lambdas in a
language neutral way. In the future, we may implement a way to share
functions between client and a server but that will most likely result
in an interface accepting something else than Function<ReadWriteEntry,
R>. Also, it's rather weird to have two EntryVersion interfaces.

Therefore I suggest moving org.infinispan.commons.api.functional to
infinispan-core, package org.infinispan.api.functional

You might say that the server-side code would use the interfaces, but
once it's running on server, it should depend on core (or core-api) -
commons is what is shared with the client, and if the client will in
future register a new function on the server, the user code should
depend on core-api as well (client-hotrod itself does not have to).

If you wonder what led me to this is that I've tried to add
SerializableFunction overloads to the FunctionalMap and found out that
SerializableFunction et all are only in infinispan-core (for good).

Please let me know if you have objections/if there something I have missed.

Radim

--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev



--

Vittorio Rigamonti

Senior Software Engineer

Red Hat

Milan, Italy

[hidden email]

irc: rigazilla 


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Moving functional API to core

Radim Vansa
In reply to this post by William Burns-3
On 06/12/2017 04:52 PM, William Burns wrote:

>
>
> On Sat, Jun 10, 2017 at 12:56 AM Radim Vansa <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi guys,
>
>     when the functional API has been outline, the interfaces were put into
>     infinispan-commons to make it possible to share these between remote
>     clients and embedded use case. However, it seems that reusing this
>     as-is
>     impossible or at least impractical as we cannot send the lambdas in a
>     language neutral way. In the future, we may implement a way to share
>     functions between client and a server but that will most likely result
>     in an interface accepting something else than Function<ReadWriteEntry,
>     R>. Also, it's rather weird to have two EntryVersion interfaces.
>
>     Therefore I suggest moving org.infinispan.commons.api.functional to
>     infinispan-core, package org.infinispan.api.functional
>
>     You might say that the server-side code would use the interfaces, but
>     once it's running on server, it should depend on core (or core-api) -
>     commons is what is shared with the client, and if the client will in
>     future register a new function on the server, the user code should
>     depend on core-api as well (client-hotrod itself does not have to).
>
>     If you wonder what led me to this is that I've tried to add
>     SerializableFunction overloads to the FunctionalMap and found out that
>     SerializableFunction et all are only in infinispan-core (for good).
>
>
> We could move these into commons in a major version if we need to as
> well. I never thought about using them in the client code as we never
> planned on supporting serialized lambdas there, but if it makes other
> things easier I am for it.
>
> Also there is nothing stopping us from having these in commons right
> now, there is nothing special about the interfaces, they can just be
> copied over.

-1 These can't be simply copied, because two modules cannot share a
package name (org.infinispan.util), therefore we would have to move the
SerializableFunction to org.infinispan.commons.util.function. But as you
say; we can't/don't want to support lambdas in any remote client
operations and therefore these would be superfluous in commons.

We have to think about a pattern for the building-blocks (counters,
locks, multimaps...): in embedded case we want to expose API using
lambdas, in remote client this should be named filter, script or Ickle
query. Obvious solution is having BaseFeature -> EmbeddedFeature,
RemoteFeature that would expose the functional operations symmetrically
but with different API, but it seems to me a bit inelegant.

Note that embedded/remote building blocks will have different
properties/behaviour anyway - e.g. for embedded it could be useful to
execute an action once the 'owning node' crashes (e.g. release a lock)
while it does not make much sense with remote client.

Radim

>
>     Please let me know if you have objections/if there something I
>     have missed.
>
>     Radim
>
>     --
>     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Moving functional API to core

William Burns-3


On Tue, Jun 13, 2017, 3:54 AM Radim Vansa <[hidden email]> wrote:
On 06/12/2017 04:52 PM, William Burns wrote:
>
>
> On Sat, Jun 10, 2017 at 12:56 AM Radim Vansa <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi guys,
>
>     when the functional API has been outline, the interfaces were put into
>     infinispan-commons to make it possible to share these between remote
>     clients and embedded use case. However, it seems that reusing this
>     as-is
>     impossible or at least impractical as we cannot send the lambdas in a
>     language neutral way. In the future, we may implement a way to share
>     functions between client and a server but that will most likely result
>     in an interface accepting something else than Function<ReadWriteEntry,
>     R>. Also, it's rather weird to have two EntryVersion interfaces.
>
>     Therefore I suggest moving org.infinispan.commons.api.functional to
>     infinispan-core, package org.infinispan.api.functional
>
>     You might say that the server-side code would use the interfaces, but
>     once it's running on server, it should depend on core (or core-api) -
>     commons is what is shared with the client, and if the client will in
>     future register a new function on the server, the user code should
>     depend on core-api as well (client-hotrod itself does not have to).
>
>     If you wonder what led me to this is that I've tried to add
>     SerializableFunction overloads to the FunctionalMap and found out that
>     SerializableFunction et all are only in infinispan-core (for good).
>
>
> We could move these into commons in a major version if we need to as
> well. I never thought about using them in the client code as we never
> planned on supporting serialized lambdas there, but if it makes other
> things easier I am for it.
>
> Also there is nothing stopping us from having these in commons right
> now, there is nothing special about the interfaces, they can just be
> copied over.

-1 These can't be simply copied, because two modules cannot share a
package name (org.infinispan.util), therefore we would have to move the
SerializableFunction to org.infinispan.commons.util.function.

I never said they had to be on the same package :-P

But as you
say; we can't/don't want to support lambdas in any remote client
operations and therefore these would be superfluous in commons.

We have to think about a pattern for the building-blocks (counters,
locks, multimaps...): in embedded case we want to expose API using
lambdas, in remote client this should be named filter, script or Ickle
query. Obvious solution is having BaseFeature -> EmbeddedFeature,
RemoteFeature that would expose the functional operations symmetrically
but with different API, but it seems to me a bit inelegant.

This is always our problem, we never have a solution and then client API falls behind.

Also even though we wouldn't serialize lambdas with client, doesn't mean we can't use lambdas with the client. Just means the operation would have slower performance, since it would be evaluated in the client.

I personally welcome the BaseFeature you mentioned because we need that asap so that we can create these API while maintaining some type of semblance between them.


Note that embedded/remote building blocks will have different
properties/behaviour anyway - e.g. for embedded it could be useful to
execute an action once the 'owning node' crashes (e.g. release a lock)
while it does not make much sense with remote client.

Radim

>
>     Please let me know if you have objections/if there something I
>     have missed.
>
>     Radim
>
>     --
>     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Moving functional API to core

Radim Vansa
On 06/13/2017 03:07 PM, William Burns wrote:

>
>
> On Tue, Jun 13, 2017, 3:54 AM Radim Vansa <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 06/12/2017 04:52 PM, William Burns wrote:
>     >
>     >
>     > On Sat, Jun 10, 2017 at 12:56 AM Radim Vansa <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     Hi guys,
>     >
>     >     when the functional API has been outline, the interfaces
>     were put into
>     >     infinispan-commons to make it possible to share these
>     between remote
>     >     clients and embedded use case. However, it seems that
>     reusing this
>     >     as-is
>     >     impossible or at least impractical as we cannot send the
>     lambdas in a
>     >     language neutral way. In the future, we may implement a way
>     to share
>     >     functions between client and a server but that will most
>     likely result
>     >     in an interface accepting something else than
>     Function<ReadWriteEntry,
>     >     R>. Also, it's rather weird to have two EntryVersion interfaces.
>     >
>     >     Therefore I suggest moving
>     org.infinispan.commons.api.functional to
>     >     infinispan-core, package org.infinispan.api.functional
>     >
>     >     You might say that the server-side code would use the
>     interfaces, but
>     >     once it's running on server, it should depend on core (or
>     core-api) -
>     >     commons is what is shared with the client, and if the client
>     will in
>     >     future register a new function on the server, the user code
>     should
>     >     depend on core-api as well (client-hotrod itself does not
>     have to).
>     >
>     >     If you wonder what led me to this is that I've tried to add
>     >     SerializableFunction overloads to the FunctionalMap and
>     found out that
>     >     SerializableFunction et all are only in infinispan-core (for
>     good).
>     >
>     >
>     > We could move these into commons in a major version if we need to as
>     > well. I never thought about using them in the client code as we
>     never
>     > planned on supporting serialized lambdas there, but if it makes
>     other
>     > things easier I am for it.
>     >
>     > Also there is nothing stopping us from having these in commons right
>     > now, there is nothing special about the interfaces, they can just be
>     > copied over.
>
>     -1 These can't be simply copied, because two modules cannot share a
>     package name (org.infinispan.util), therefore we would have to
>     move the
>     SerializableFunction to org.infinispan.commons.util.function.
>
>
> I never said they had to be on the same package :-P
>
>     But as you
>     say; we can't/don't want to support lambdas in any remote client
>     operations and therefore these would be superfluous in commons.
>
>
>     We have to think about a pattern for the building-blocks (counters,
>     locks, multimaps...): in embedded case we want to expose API using
>     lambdas, in remote client this should be named filter, script or Ickle
>     query. Obvious solution is having BaseFeature -> EmbeddedFeature,
>     RemoteFeature that would expose the functional operations
>     symmetrically
>     but with different API, but it seems to me a bit inelegant.
>
>
> This is always our problem, we never have a solution and then client
> API falls behind.

Speaking about clients falling behind, do we have the remote counters
somewhere on the roadmap? I think that OGM's need of sequences was one
of the primary motivations, but OGM is now focusing more on the Hot Rod
integration.

>
> Also even though we wouldn't serialize lambdas with client, doesn't
> mean we can't use lambdas with the client. Just means the operation
> would have slower performance, since it would be evaluated in the client.

That defies the point completely. I wouldn't trick the user into
thinking that the operation happens in place unless we have a plan to
fix that **soon**.

>
> I personally welcome the BaseFeature you mentioned because we need
> that asap so that we can create these API while maintaining some type
> of semblance between them.
>
>
>     Note that embedded/remote building blocks will have different
>     properties/behaviour anyway - e.g. for embedded it could be useful to
>     execute an action once the 'owning node' crashes (e.g. release a lock)
>     while it does not make much sense with remote client.
>
>     Radim
>
>     >
>     >     Please let me know if you have objections/if there something I
>     >     have missed.
>     >
>     >     Radim
>     >
>     >     --
>     >     Radim Vansa <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>
>     >     JBoss Performance Team
>     >
>     >     _______________________________________________
>     >     infinispan-dev mailing list
>     > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     >
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > [hidden email]
>     <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>     --
>     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...