orpiske commented on PR #22158: URL: https://github.com/apache/camel/pull/22158#issuecomment-4175473268
> ``` > # Caffeine example > camel.beans.caffeineBackend = #class:org.apache.camel.component.statestore.caffeine.CaffeineStateStoreBackend > camel.beans.caffeineBackend.maximumSize = 50000 > > # Redis example > camel.beans.redisBackend = #class:org.apache.camel.component.statestore.redis.RedisStateStoreBackend > camel.beans.redisBackend.redisUrl = redis://myhost:6379 > camel.beans.redisBackend.mapName = my-app-state > > # Infinispan example > camel.beans.infinispanBackend = #class:org.apache.camel.component.statestore.infinispan.InfinispanStateStoreBackend > camel.beans.infinispanBackend.hosts = myhost:11222 > camel.beans.infinispanBackend.cacheName = my-cache > ``` > > This sounds fine, but from a usability perspective, it would be nice to be able to reuse the existing Camel Infinispan or Redis components. This is not the first time we are "reinventing the wheel" for this kind of use case. > > Given that we already have Infinispan and Redis components with their own configurations — which are supposed to be more feature-rich than the current state store implementation — I was wondering whether we could find a way to reuse those components (or at least part of their logic) for these use cases. > > fyi @gnodet @orpiske @oscerd @apupier **Pros:** - I like the consistency - I like that it has a swappable backend - I like the simplicity of the API **Cons:** - We already have code that does this, even though it's inconsistent it is well known and documented - The existing code already fits into Camel idioms So, I am not opposite to have this one on the code base and I think there is potential for making stateful operations/caching a bit more elegant. The consistent of the operations make the behavior a bit more predictable regardless of the backend in use. However, I believe that we should have a greater discussion about what our vision and/or medium term goals for the problem should be. Even if the API is elegant, it may not be enough if we don't collectively share the same vision about how we would like this to be. As such, I'm currently leaning towards 0 on this one and would like to hear more feedback from the community before having a decision on -1 or +1 from my side. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
