On 24 Mar 2010, at 11:11, Mircea Markus wrote:
I've checked in ongoing work of the hotrod client; it would be
great to get some feedback on the public API, especially RemoteCache[1] and
RemoteCacheManager[2].
For now RemoteCacheManager does not implement CacheManager interface, see email bellow.
[1]
http://tinyurl.com/yhb793b
Looks good. Shouldn't VersionedEntry be VersionedValue<V> ?
Basically Cache.get(K) returns V. So RemoteCache.getVersioned(K) should return
VersionedValue<V> ?
Don't you want RemoteCacheManager to be an interface and a separate
RemoteCacheManagerImpl or something?
Also, maybe you want to also provide a constructor that takes in (Properties p, int
numBossThreads, int numWorkerThreads) and (Properties p, int numBossThreads, int
numWorkerThreads, ClientIntelligenceLevel cil) - or are these three (boss threads, worker
threads, client intelligence level) all defined in properties?
Cheers,
Mircea
On 23 Mar 2010, at 23:16, Mircea Markus wrote:
> Hi,
>
> While presenting the hot rod client java API in Brno, we agreed to use a
RemoteCacheManager that would implement CacheManager (similar to the way in which
DefaultCacheManager implements CacheManager; it is used for clients from the same
namespace).
> Looking at the CacheManager interface[1], most of the methods that do not make sense
on the RemoteCacheManager: defineConfiguration, getClusterName, getAddress, isCoordinator,
getStatus, getGlobalConfiguration, getDefaultConfiguration and getCacheNames.
> The only two methods that really make sense are: getCache() and
getCache(cacheName:String). So here are some thoughts I have about having
RemoteCacheManager implementing CacheManager.
> 1. Approach 1 - throw exceptions for the unsupported methods. Not a very nice
approach IMO, given the fact that most of the methods fall in this category, which would
make the API a bit unusable
> 2. Approach 2 - do not extend it. This would result in a clearer API
> 3. Approach 2 - Extract the two getCache methods in an super interface (CacheHolder,
CacheRepository, ??) and have both CacheManager and RemoteCacheManager implement it - this
one I like the most as it encourages reusability and keeps the API clean.
>
> Thoughts?
>
> Cheers,
> Mircea
>
> [1]
http://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/in...
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org