On May 24, 2010, at 11:13 AM, Chris Dennis wrote: > Hi All: > > I know that this is probably going to see some fairly heavy > refactoring in the coming days anyway but I figured it was good > starting point for these specification discussions and any decisions/ > thoughts will most likely map easily to any future refactored form... > > Generic Question: > 1: Should the interface specification allow limitation of the form of > the names used for the generated clustered objects? Probably :-)
> 2: How should the namespaces be defined for the different types of > objects? Not sure > > getBarrier, getBlockingQueue: > 1: What should happen if a queue/barrier exists for the given name, > but with a non-matching property (e.g. parties)? Hmmm, I think in some cases it might be hard to detect this in all cases? Should we have methods like, queueExists, createIfAbsent type stuff? > > getDistributedCacheConfig: > 1: Should be called CacheMaker/CacheFactory? That would make clearer > what it does. What about getNewDistributedCacheMaker()? > > I know that the following methods are marked as needing refactoring, > but a couple of them I figured could do with discussion: > > createLock: > 1: Unclustered monitor object results in? (then what happens if > monitor object subsequently becomes clustered?) We don't support that do we? > 2: Null monitor object leads to? Exception? > 3: Null lock type leads to? Exception? > > lookupOrCreateRoot > 1: Existing root with mismatched type results in? > 2: Exception in creator results in? > > That should get the ball rolling... > > Chris > > _______________________________________________ > tc-dev mailing list > tc-dev@lists.terracotta.org > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
