Thanks Galder and Pedro. I'll implement them as you suggested! Cheers On 2017-11-03 6:02 AM, Galder Zamarreño wrote: At first glance, I'd agree with Pedro. On 2 Nov 2017, at 16:07, Pedro Ruivo <pedro(a)infinispan.org&gt; <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 listinfinispan-dev@lists.jboss.orghttps://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