I did but then forgot, long day. Anyway, doesn't feel terracotta specific. Maybe ClusterLock?
On May 19, 2010, at 9:59 PM, Geert Bevin wrote: > 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 _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
