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