> Instead of the standard port 389, specify port 3268, and the freezing is
> gone.
- Does not really help if LDAP cannot be reached there. It gets faster but does not look up the entries in my case. This is almost equivalent to deleting the LDAP entry itslf. (this is no workaround, but a shutdown of functionality)
Essentially the UI seems to wait for any response from the LDAP before it times out after 10 s, which is a really bad behavior for user interaction.
Whilst not knowing the code there seems to be a major misconception not to allow for asynchronous searches. -Wondering how successful Google would be if their UI would freeze for 10 s every time anything is typed into their search box.
For us it is a major problem especially when using a laptop that cannot reach an existing Server (e.g. outside a firewall) tbird stalls in mid air.
As a result currenty LDAP lookups in tbird have to be considered as broken, if one does not want to avoid tbird altogether.
> Instead of the standard port 389, specify port 3268, and the freezing is
> gone.
- Does not really help if LDAP cannot be reached there. It gets faster but does not look up the entries in my case. This is almost equivalent to deleting the LDAP entry itslf. (this is no workaround, but a shutdown of functionality)
Essentially the UI seems to wait for any response from the LDAP before it times out after 10 s, which is a really bad behavior for user interaction.
Whilst not knowing the code there seems to be a major misconception not to allow for asynchronous searches. -Wondering how successful Google would be if their UI would freeze for 10 s every time anything is typed into their search box.
For us it is a major problem especially when using a laptop that cannot reach an existing Server (e.g. outside a firewall) tbird stalls in mid air.
As a result currenty LDAP lookups in tbird have to be considered as broken, if one does not want to avoid tbird altogether.