Server Selection
Greg Whalin
gwhalin at meetup.com
Thu Dec 8 13:35:39 UTC 2005
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?
Greg
More information about the memcached
mailing list