On Jan 28, 9:39 pm, "jmai...@ttec.com" <jmai...@ttec.com> wrote:
> On Jan 28, 10:16 pm, Howard Chu <XYZ....@highlandsun.com> wrote:
>
> > It's already well established that sendmail's built in LDAP support has
> > severe performance problems when used for the access_db.

> Make a patch that adds either a new map type such as ldapcache or
> parameter to ldap which handles converting iterative queries
> internally into cacheable data -- theory being that if it is self
> encapsulating it is no worse than all the other _FFR features which
> can be used by those who know how and can be picked up by sendmail.org
> without too much of a fuss.

Thanks for responding.

I already proposed a caching solution, that proposal didn't fly
either. I agree with Claus' reasons there too - the goal is to cut
down the number of map lookup invocations. Caching is only half a
solution, and it adds a lot of unnecessary complexity to the LDAP map
code.

> Butting heads with Claus and sendmail.org s no one. (Disclaimer:
> They havent taken any of my feature patches either, so my advice may
> be worth diddly.)

We may be butting heads, but I posted this thread on his
recommendation.
1) to lay out more details of the proposed changes
2) to get feedback from the newsgroup

> Perhaps you could even have it fall back to old style query in certain
> circumstances.

I think if the map is defined with the -I option there's no reason to
use the old style query. And if the map is not defined with the -I
option, then it will only use the old style query.