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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
