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

[Tristan Tarrant]

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