[infinispan-dev] HotRod, ClientIntelligence and client-side key location

[Mircea Markus]

On 20 Apr 2010, at 16:58, Manik Surtani wrote:

> 
> On 16 Apr 2010, at 23:45, Mircea Markus wrote:
> 
>> 
>> On 14 Apr 2010, at 10:22, Galder Zamarreno wrote:
>> 
>>> Apologies for the delay getting back to this. I think Mircea does have a point here. 
>>> 
>>> I think his suggestion might make the the hash function parameters more future proof at the cost of a vInt for the parameter number and a String with the parameter name in the response.
>> +1. This is more generic and the cost is only one additional param (int?), that's only sent once per HR client.
>>> 
>>> I can't however give individual examples on parameters that'd be needed in the future.
>> What about virtual node count, for a function that uses virtual nodes?
> 
> There is no guarantee that we'd ever implement a virt node mechanism.  
sure, but we might implement it, and somebody else might implement other functions that need other params
> 
>>> 
>>> Mircea, what did you refer to by sending number of owners? We already do that in the current protocol spec.
>> I missed that.
>>> 
>>> Cheers,
>>> 
>>> ----- "Mircea Markus" <mircea.markus at jboss.com> wrote:
>>> 
>>>> On 6 Apr 2010, at 19:37, Manik Surtani wrote:
>>>> 
>>>>> 
>>>>> On 2 Apr 2010, at 00:59, Mircea Markus wrote:
>>>>> 
>>>>>>> I foresee making the hash space size a tuning parameter in the
>>>> future.  This is independent of hash function used.   
>>>>>> Are all the hash functions going to have an hash space parameter?
>>>> Other functions might need some additional config params. What about
>>>> not "hardcoding" params in the protocol itself, but use a generic way
>>>> to send them over:
>>>>>> ... bytes[ h f version] [param number] [param name 1] [param value
>>>> 1] etc.
>>>>>> Each function should be able to read its own params. 
>>>>> 
>>>>> 
>>>>> I don't see what other params could exist?  Any examples?
>>>> nr of virtual nodes for a different implementation. In future we might
>>>> also want to send the number of owners. Another impl might come with
>>>> its own params.
>>>>> 
>>>>> --
>>>>> Manik Surtani
>>>>> manik at jboss.org
>>>>> Lead, Infinispan
>>>>> Lead, JBoss Cache
>>>>> http://www.infinispan.org
>>>>> http://www.jbosscache.org
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100420/4966923e/attachment-0001.html