Explanation:
Alternative would be to leave type empty, as it is when contact comes form SQL source.
But this feels overly ambiguous and may cause problems in the future.
Reason:
In order to enable development of sophisticated autocomplete algorithms, they will need
to process all the data relevant to autocomplete - what was the search string and which
result was the correct one.
Example to illustrate the need:
Say we are talking about these two people of interest, who are in the address book, among others:
- person 1: Bostjan Skufca <bostjan@a2o.si>
- person 2: Bostjan SkuBIC <bostjan@otherdomain.com>
Our user is used to think about the first person by the first name, "Bostjan", as he is an old friend.
The second one is a colleague at work where people call themselves mostly by surnames, "Skubic" in this case.
Without this data provided to 'autocomplete_insert', there is no way for RC to learn that when our user
enters "bos" in the To: field he thinks about person #1 (Bostjan SkuFCA), and when he starts typing "sku"
he means person #2 (Bostjan SkuBIC).
Two reasons:
- provide it to plugin backend functions that use 'contacts_autocomplete_after' hook
- provide it to frontend
Why to frontend?
If plugin JS adds an 'autocomplete_insert' hook we need to provide it with exact
autocomplete data. Providing it with name and email address only, without pinpointing
exact origin of this autocomplete result, will severely limit learning capabilities of
potential future autocomplete implementations.
Reason:
Having genericly named variable $id in nested loops makes code unreadable.
Replacing generic name '$id' with '$ENTITIY_id' format removes all ambiguity.
Provide existing list of contact suggestions as an argument - it might be unclear
now what logic plugin developers decide to implement, but data for that logic
should be provided upfront, and that includes list of suggestions that RC
itself comes up with.
Plugin logic might then replace the list entirely, or just rearrange its entries, or use
part of the list when it runs out of own ideas, or do something entirely different.
Symptom
=======
When using roundcube with mailboxes with over 60k messages, list
view was way faster than viewing in threaded view.
Mailbox index view timing: ~360 ms
Mailbox threaded view timing: ~800 ms
Resolution
==========
Use native PHP array manipulation functions instead of rolling custom
string data reversal implementation using strpos() and substr() in a
'while' loop.
This optimization is already present in index view handler, but was missing
from threaded view.
Results after optimization
==========================
Both average out around ~360 ms response time.
Bostjan Skufca