[infinispan-dev] Moving functional API to core
Radim Vansa
rvansa at redhat.com
Tue Jun 13 10:11:37 EDT 2017
On 06/13/2017 03:07 PM, William Burns wrote:
>
>
> On Tue, Jun 13, 2017, 3:54 AM Radim Vansa <rvansa at redhat.com
> <mailto:rvansa at redhat.com>> wrote:
>
> 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>
> > <mailto: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.
>
>
> 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 <rvansa at redhat.com <mailto:rvansa at redhat.com>
> <mailto: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>
> <mailto: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
> <mailto:infinispan-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> 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
More information about the infinispan-dev
mailing list