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