Merged into FRAMEWORK_3 as well.

Having suggested it, I think it may actually be the best the way it 
is, only because there is no other cue anywhere that tells the user 
that the address book they want to browse is not browseable.  In other 
words, the flaw in my original logic is that if a user wants to 
browse, they'll know which address books are browseable, but in 
reality, they probably don't know that, because thats an 
administrative option.

Fixed in HEAD - only the part about performing the search before we 
know if the source is browseable.  What does everyone think about the 
suggestion to "fall through" to the first browseable addressbook we 
find in the Turba::getAddressbooks?

I have multiple address books configured to use and have selected 
which ones to use and the order they will be displayed and searched.



For simplicity's sake, I'll use two for an example.



1) LDAP directory - physically read-only, browse -> false

2) localsql - My Addressbook, read/write



When I click on the browse button, there is a very perceptible five 
second or so pause and then the following notification: "Your default 
addressbook is not browseable."  A list of browseable addressbooks (in 
this case, and actually all current cases for our installation) is 
shown in the upper right, with My Addressbook.



It seems that if Browse is chosen from the menu, the first available 
browseable address book should be browsed, instead of trying the 
default, finding all the results, then checking to see if its 
browsable.  I'm just speculating that's what's happening, based on the 
timing of how long a search for all users normally takes.