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

Reply via email to