[infinispan-dev] Moving functional API to core

[Radim Vansa]

On 06/12/2017 04:52 PM, William Burns wrote:
>
>
> On Sat, Jun 10, 2017 at 12:56 AM Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> 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 <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team