Re: [infinispan-dev] (Not-so-)optional cachestores

Yes, that would be nice. I found another "cons" for #4: an embedded config would not translate 1:1 to server. Well, it doesn't translate directly now either, but at least it's "closer". Tristan On 25/01/2016 15:39, Radim Vansa wrote: > Would the deployable cache stores benefit from 4) as well? It seems to > me as the only 'right' option. > > R. > > On 01/25/2016 02:29 PM, Tristan Tarrant wrote: >> Hi all, >> >> Jakub has recently revived the Cassandra Cache Store (CCS from now on) >> which, as you all will remember, was pushed to an external repository >> where it lay in abandonment ever since. >> >> We now need to add support for this store to Infinispan Server, but >> unfortunately, because of the "monolithic schema" approach that WildFly >> imposes on subsystems, this has to be done within the Infinispan >> subsystem itself. >> This creates a conundrum, since the CCS depends on Infinispan core, >> server would depend on the CCS but server is part of the Infinispan build. >> >> Possible solutions: >> 1) move the CCS back into the main repo >> - pros: no more conundrum, built by default, easier to maintain >> - cons: makes the repo even bigger, binds the lifecycle of the CCS >> to Infinispan's >> 2) extend the server to be able to interpret the CCS schema but not >> actually depend on its code and provide the code to instantiate the CCS >> as an overlay module which can be installed on server >> - pros: keeps the lifecycle of the CCS independent >> - cons: additional complexity to handle the split, forces us to >> still keep server aligned with schema changes in the CCS itself. >> 3) make the CCS a deployable cache store >> - pros: easiest >> - cons: not really ootb experience, no nice schema >> 4) create a dedicated subsystem for the CCS and "invent" a way to >> reference it from the main Infinispan subsystem using a naming >> convention, similar to how datasources are currently implemented. >> - pros: keeps the two projects independent, reusable for other >> Cachestores >> - cons: writing a subsystem from scratch is complex (although bits >> of it could be made reusable for multiple cachestores). >> >> Your thoughts please. >> >> Tristan > > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev