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

On 06/12/2017 04:52 PM, William Burns wrote: > > > On Sat, Jun 10, 2017 at 12:56 AM Radim Vansa <rvansa(a)redhat.com > <mailto:rvansa@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.

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(a)redhat.com <mailto:rvansa@redhat.com>> > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org <mailto: infinispan-dev(a)lists.jboss.org&gt; > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev