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