Server Selection
Greg Whalin
gwhalin at meetup.com
Thu Dec 8 14:52:31 UTC 2005
Alex Stapleton wrote:
>
> On 8 Dec 2005, at 13:35, Greg Whalin wrote:
>
>> Alex Stapleton wrote:
>>
>>> On 8 Dec 2005, at 10:03, Alex Stapleton wrote:
>>>
>>>>
>>>> On 6 Dec 2005, at 14:06, Gregory Block wrote:
>>>>
>>>>> On 6 Dec 2005, at 13:59, Greg Whalin wrote:
>>>>>
>>>>>>
>>>>>> This is 100% correct. I guess I had never envisioned people
>>>>>> putting the order in different. I would not feel comfortable re-
>>>>>> sorting the list in the event that the user intentionally set
>>>>>> the order for some reason (can't think of a very compelling one
>>>>>> off the top of my head, but does not mean there is not one).
>>>>>
>>>>>
>>>>>
>>>>> The knee-jerk answer: Because that's the way it's done on other
>>>>> clients, and as such, behaviours between clients match? :)
>>>>>
>>>>> I don't feel there's a good reason to sort in-client unless all
>>>>> the clients do so; there's no point in behaving differently, as
>>>>> it breaks compatibility with any perl-based commandline tools
>>>>> one might write to access the same data.
>>>>>
>>>>> If someone wants to sort, they can sort on the way in, IMO.
>>>>
>>>>
>>>>
>>>> why not just add something like
>>>>
>>>> memcache_sort_severs()
>>>>
>>>> so that if people want to ensure they are always in the same
>>>> order, they can really easily?
>>>
>>> *tries again with better spelling*
>>> What I mean, is you could just add a single method which sorts the
>>> server list for the user when it's called. That way they can do
>>> weird ordering tricks if they really want to. It's not like it
>>> really *needs* to reduce flexibility. It could always be some sort
>>> of toggleable option as well, so that you use the original or
>>> sorted server list at will if you want to mix the two behaviours
>>> without having to recreat the server list.
>>
>>
>>
>> As I see it, this would increase complexity without need. I still
>> can see no reason that something like this would ever be needed?
>
>
> Well if it's enabled by default and is set up as a toggleable flag then
> depending on the default (sort the list?) people who want it sorted
> (presumably most of them) would not have to worry about changing any
> code, and it would just-work (tm). Anyone crazy enough to want to do
> use different server list orders can always disable it and do their
> crazy crap.
>
> As nobody has requested to actually be able to user different orders
> and there isn't a particularly obvious reason to want to do it anyway,
> it doesn't seem unreasonable to just be lazy about it and just
> automatically sort it and not let people disable that behaviour until
> someone comes up with a compelling reason to do it differently.
Again though, this is unneeded and adds complexity where none is needed.
It works fine as it is now and all clients essentially do the same
thing. Nobody can say why this would be useful in any way.
Adding/changing code always introduces the possibility that bugs will be
introduced. All I can say is that the java client will not be adding
this feature anytime soon. If others really want it, the client is open
source, so have at it. :)
Greg
More information about the memcached
mailing list