Re: [infinispan-dev] Counters and their configurations in Infinispan server (DMR)

At first glance, I'd agree with Pedro. > On 2 Nov 2017, at 16:07, Pedro Ruivo <pedro(a)infinispan.org&gt; wrote: > > Hi, > > IMO, I would separate the concept of counter and configuration. > > Even if an user doesn't create many counters, I think most of them will > share the same configuration. As a bad example, if you want to counter > oranges and apples, you're going to use the same configuration... > probably :) > > In addition, it is symmetric to the cache DMR tree. This would reduce > the learning curve if the user is already used to cli (i.e create > caches). > > Cheers, > Pedro > > > > On 02-11-2017 12:33, Vladimir Blagojevic wrote: >> Hey guys, >> >> How do you anticipate users are going to deal with counters? Are they >> going to be creating a lot of them in their applications, say dozens, >> hundreds, thousands? >> >> I am asking because I have a dilemma about their representation in DMR >> and therefore in the admin console and potentially wider. The dilemma is >> related to splitting the concepts and the mapping between counter >> configuration and counter instances. On one end of the possible spectrum >> use, if users are going to have many counters that have the same >> configuration then it makes sense to delineate the DMR concept of the >> counter configuration and its counter instance just like we do for >> caches and cache configuration templates. We deal with cache >> configurations as templates; one could create hundreds of caches from >> the same template. Similarly, we can do with counters. On the other end >> if users are going to create very few counters then it likely does not >> make much sense to separate counter configurations from its instance, >> they would have one to one mapping. For each new counter, users would >> just enter counter configuration and launch an instance of a >> corresponding counter. >> >> The first approach saves resources and makes large counter >> instantiations easier while the second approach is easier to understand >> conceptually but is inefficient if we are going to have many counter >> instance. >> >> Thoughts? >> >> Vladimir >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Infinispan, Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev