sure, but we might implement it, and somebody else might implement other functions that need other paramsOn 16 Apr 2010, at 23:45, Mircea Markus wrote:On 14 Apr 2010, at 10:22, Galder Zamarreno wrote:+1. This is more generic and the cost is only one additional param (int?), that's only sent once per HR client.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.What about virtual node count, for a function that uses virtual nodes?
I can't however give individual examples on parameters that'd be needed in the future.There is no guarantee that we'd ever implement a virt node mechanism.
______________________________________________________________________________________________I missed that.
Mircea, what did you refer to by sending number of owners? We already do that in the current protocol spec.
Cheers,
----- "Mircea Markus" <mircea.markus@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 thefuture. 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 aboutnot "hardcoding" params in the protocol itself, but use a generic wayto send them over:... bytes[ h f version] [param number] [param name 1] [param value1] 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 mightalso want to send the number of owners. Another impl might come withits own params.--Manik Surtanimanik@jboss.orgLead, InfinispanLead, JBoss Cachehttp://www.infinispan.orghttp://www.jbosscache.org_______________________________________________infinispan-dev mailing listinfinispan-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev_______________________________________________infinispan-dev mailing listinfinispan-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev--Manik SurtaniLead, InfinispanLead, JBoss Cache
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev