Just checking, did you read my explanations underneath the list. I'm wondering since you say you don't know what TerracottaLock is.
-- Geert Bevin Terracotta - http://www.terracotta.org On 20 May 2010, at 02:23, Steve Harris <st...@terracottatech.com> wrote: > 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 _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev