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
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev

Reply via email to