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

[Tristan Tarrant]

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