Thanks for the feedback!
On 25 Mar 2010, at 02:18, Manik Surtani wrote:
> 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> ?
good point. It's a Entry<K,V>, as it extends Map.Entry<K,V
>>
[2]
http://tinyurl.com/yh6j2we
> Don't you want RemoteCacheManager to be an interface
and a separate RemoteCacheManagerImpl or something?
I've been thinking about that; I wanted to copy the behaviour from core, in which we
instantiate the DefaultCacheManagers directly.
> 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?
these will all be defined in properties. It might make sense having an constructor that
takes all the config props though.
>
>>
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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev