On Mon, Jul 25, 2016 at 10:03 AM Galder Zamarreño <gal...@redhat.com> wrote:
> > > On 22 Jun 2016, at 17:44, Radim Vansa <rva...@redhat.com> wrote: > > > > I've spotted things like 'decorating cache' in the wiki page. I though > > that the core architecture in Infinispan, modifying the behavior > > according to configurations, is the interceptor stack. While we have > > some doubts about its performance, and there are limitations - e.g. the > > Flags don't allow to add custom parameters and we certainly don't want > > to add Flag.JSON and Flag.XML - I would consider decorating a Cache<K, > > V> vs. adding interceptors. > > > > I am thinking of adding the transcoder information to invocation context > > and only pass different ICF to the CacheImpl. Though, this requires new > > factory, new interceptor and a handful of specialized context classes > > (or a wrapper to the existing ones). Whoo, just decorating Cache sounds > > much simpler (and probably more performant). Or should we have forks in > > interceptor stack? (as an alternative to different wrappers). > > > > The idea of interceptors is that these are common for all operations, if > > we want to do things differently for different endpoints (incl. > > embedded), decorating probably is the answer. > > > > My 2c (or rather just random thoughts and whining) > > Will and I had a good discussion on the problems that interceptors had > with data conversion layers while at Summit/DevNation. I don't remember the > details very well, that's what 3 weeks of holiday does to you ;), but Will > will reply with some more details. From what I remember, doing conversion > in interceptors made did not fully work with streams and custom filters. > Sorry for the delay. The issue from what I remember is mostly what you said Galder. Streams in particular are interesting because you may have a Stream<byte[], byte[]> but underneath it is really a Stream<Object, Object> so if you try to pass an intermediate operation such as filter or map, you would pass a Predicate<? super byte[]> but that can't be applied to the underlying stream without first unboxing the key/value but then the value returned from the stream may not know if the value is unboxed or not. It is just quite messy. I don't even remember how this works when protobuf is also in the mix :( Filters are somewhat similar but they are mostly okay because they only apply at most 1 filter/map method and then use an iterator where as a stream could be any number. > > Cheers, > > > > > Radim > > > > On 06/21/2016 09:49 AM, Tristan Tarrant wrote: > >> Hi all, > >> > >> I've created a wiki [1] for the "compatibility 2.0" ideas we talked > >> about recently at the query meeting. > >> > >> This is mostly a dump of the minutes, so the form is not complete, but > >> initial comments are welcome. > >> > >> > >> Tristan > >> > >> [1] https://github.com/infinispan/infinispan/wiki/Compatibility-2.0 > > > > > > -- > > 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 > > > _______________________________________________ > infinispan-dev mailing list > 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
