This is always tough for me. On the one hand the whole point of packages is so that you don't have to put Terracotta in names like Cluster. On the other hand it can be a bit annoying when doing imports and writing code if you have more than one thing called "Node."
One pro of not having Terracotta in the naming is if we want to eventually make the toolkit a standard. That's kind of a long shot but could happen. TerracottaMap feels a bit awkward for sure. ConcurrentDistributedMap was kind of a good name but we used it elsewhere right. I guess I would do the following at first thought. Not sure if we should have a special interface for blocking queue. Don't have any specific reasons why other than the fact that we do for a lot of the other stuff. > org.terracotta > api > ClusteringClient (maybe) > cluster > Cluster > ClusterEvent > ClusterListener > ClusterTopology > ClusterNode > UnclusteredObjectException > collections > MapSizeListener > ClusterMap > coordination > ClusterBarrier > locking > FinegrainedLock > LockableMap > LockStrategy > LockType > ReadLock > ReadWriteLock > TerracottaLock <<<--- Not sure what this is > WriteLock > logging > ClusterLogger > properties > ClusterProperties > util > TextBucket > > java.util.concurrent.BlockingQueue On May 19, 2010, at 8:31 AM, Geert Bevin wrote: > Hi, > > It was rightly brought up yesterday that there's not really a consistent > approach towards the naming of our public interfaces in the toolkit. I'm > sending out this email to start the discussion about it. > > This is the current hierarchy for the app dev (the TIM dev has other > appropriate types also): > > org.terracotta > api > ClusteringProvider > cluster > TerracottaCluster > TerracottaClusterEvent > TerracottaClusterListener > TerracottaClusterTopology > TerracottaNode > UnclusteredObjectException > collections > MapSizeListener > TerracottaMap > coordination > Barrier > locking > FinegrainedLock > LockableMap > LockStrategy > LockType > ReadLock > ReadWriteLock > TerracottaLock > WriteLock > logging > TerracottaLogger > properties > TerracottaProperties > util > TextBucket > > java.util.concurrent.BlockingQueue > > So the instance of the ClusteringProvider interface is obtained by > instantiating StandaloneClusteringProvider and giving the URL of the TC > server as the constructor argument. > > Anything in the "cluster" package provides information that is specific to > the Terracotta cluster, which is why it's prefixed with Terracotta. The same > applies to TerracottaLogger and TerracottaProperties, these are really bound > to TC itself in that they log into the TC log files and provide access to the > properties that TC uses. > > Then there's the TerracottaLock which does most basic lock operations but > with additional methods that makes sense for Terracotta (currently only > isHeldByCurrentThread for any lock level). FinegrainedLock extends > TerracottaLock in that it allows lock levels to be passed in for each lock > operation in a fine-grained manner as opposed to have a default lock level > for all methods on the lock instance. LockableMap, LockStrategy and LockType > might have to be prefixed with Terracotta if we follow what I explained until > now since they're quite bound to our locking features. ReadLock, > ReadWriteLock and WriteLock are totally generic locking functionalities. > > TextBucket basically is a StringBuilder that only provides you with > append(txt) and toString() so that there's a basic interface to implement for > clustered text storage. > > TerracottaMap is a regular ConcurrentMap that also implements LockableMap, > but adds more methods that are needed for optimal cluster performance. It's > not really TC-bound except for implementing LockableMap so maybe we should > rename it to ClusteredMap? > > There you have it ... rename away! ;-) > > Geert > > -- > Geert Bevin > Terracotta - http://www.terracotta.org > > _______________________________________________ > 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
