[infinispan-dev] Compatiibility 2.0 dump

[William Burns]

On Mon, Jul 25, 2016 at 10:03 AM Galder Zamarreño <galder at redhat.com> wrote:

>
> > On 22 Jun 2016, at 17:44, Radim Vansa <rvansa at 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 <rvansa at redhat.com>
> > JBoss Performance Team
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160803/9cf68986/attachment-0001.html