While better backend searching is definitely still a goal, the main 
issues of this ticket have been resolved - we default to 'A' if there 
are too many objects on the page.

Why? We could still use the user preference to display (aggregated) 
name fields, or only show them as separate columns. Company names are 
no problem either, because any sane user would put them completely 
into the last name field anyway if he has separate fields.
The same is true for first name sorting then, because we don't know 
which format the name fields have. We could only sort for name then, 
whatever that means.
That would be the cleanest solution, but I bet that people who rely on 
the name format preference won't like it.

I don't really remember, but my opinion now is that while seperating 
the name field makes some things easier, it also implies that the 
application knows what a name looks like in a way that's not always 
going to be right - makes putting in an entry for a company more 
awkward, for instance.



Of course, if the program isn't going to make assumptions, then we 
really shouldn't have the "sort by last name" feature either.



If it's doable and not too confusing, I'd like to see us go to a model 
where you can only sort by last name if last name is a seperate field. 
That way it can be fast for everyone and there's the option to have 
the composite name field for those who want it, without the baggage of 
trying to treat it as anything other than a string.

I don't have a bright idea either, but maybe this is another good 
reason to use separate first/last names by default. What was the 
reason for the (composite) name field initially? The LDAP cn attribute?

Maybe we should default to using separate fields, and still offer the 
formatting capabilities for full name fields where necessary. The 
paging could be supported server side for separate fields then.

Currently, the paging works based on the first character of the 
displayed 'name' field - which is dependent on the user's name format 
prefs.  How would we go about filtering server-side without making 
assumptions about the field structure on the backend?  In other words, 
we can check the prefs and see we are displaying "Lastname, Firstname" 
but how can we search for this server side - not knowing if there is a 
'Lastname" field available, and if it is, what is it called?  I 
thought of putting a 'paging_search' entry into $cfgSources, but that 
would force the name format pref to be the same  system wide, not per 
user...  We could put it into the user prefs, but would something like 
this be intuitive to the user?



Thoughts?

We don't currently have a preference for which page to start with 
(instead of all), and we do filtering client-side. We should fix both 
of those, but patches would help immensely.

The browse view should display the default address book meanwhile. Not 
sure about the paging issue, has this been resolved already?

When I choose Browse from the menu, the default is to display All the 
contacts. I have many contacts in my LDAP address book and it tooks 
too long to list them all.  It would be good to add a setting into the 
preferencies to set default first  listing in the Browse. The same 
problem I encounter while composing an email in the IMP and choosing 
the addressbook.



BUT something more. When I choose to display only names beginning with 
a letter "Y", it tooks as long as I would display all the entries, 
although there are no such names. I see on the LDAP server that sldap 
proccess is running during that time at nearly 100%. It leads me to 
the fact that the filtering is done on the client side (client = 
php@apache, server = LDAP). Is it like that? If yes, please consider 
to query only the contacts beginning with the specific letter. If not, 
then the problem is maybe with the OpenLDAP server I use.