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) 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
