Oh, the other thing that I've been seriously considering is making an
OpenLDAP backend that interfaces into some of the Cyrus information.
Instead of having the IMAP server contact an LDAP server for
information, run an LDAP server on the IMAP server that exports the
information you're interested in.
The thought behind this is that the IMAP server is exporting data
(accounts, mailboxes, etc.) that are intrinsically seperate from
another LDAP server. So instead of trying to slave one to another,
have an LDAP server that exports the exact data (and can be referred
to from your primary server).
Larry
Date: Fri, 17 Aug 2001 13:32:19 -0400
From: "Kevin J. Menard, Jr." <[EMAIL PROTECTED]>
Organization: Worcester Polytechnic Institute
So, I started looking at implementing this last night, and decided there's
quite a few changes that need to be made. There's a lot of mickey-mousing
that needs to be done since the existing quota lookups deal with fd (no big
surprise there), and memory map functions that expect them. Plus I couldn't
cut the fd out completely, since the amount of the quota used is still
recorded in the quota file :-/
So, I started coding away, conditionally blocking things off and what not,
and then it hit me. . .
Sure, I'm doing an LDAP quota lookup, but 100:1 says someone else out there
wants to do MySQL lookups, or PostgresSQL lookups. So, sure, I patch it now
for LDAP, and then someone else is gonna have to duplicate the work to get
any other sort of lookup going. My solution? Write an abstracted
interface, which then deals with each type of look up. Problem is, new code
will still have to be added somewhere, but it'll be a hell of a lot easier.
And imapd.c itself wouldn't have to change each time.
Then something else hit (it's amazing how this all hits me at 1 AM :)).
Right now, I'm just doing quota lookups, but what if later down the road
LDAP was to be used for something else? Devdas Bhagat mentioned using LDAP
lookups for the virtual domain stuff. My solution again? Creating a couple
new files (for LDAP in this case -- other people can do the other stuff), to
handle global connections and searches. That means, function definitions
that are abstracted enough as to be useful in multiple cases. Only reason
I'm saying this is, because it'd be a waste to write the connection code
once in the quota lookup section, then again for mailboxes, and then again
for whatever else.
So, my point of all this is to get people's feelings on this. Does what I
propose sound like the right direction to take? Is there enough support to
merit doing this? What's needed in order to get the code merged with the
existing branch (ideally that's what would happen)? Any info at all would
be greatly appreciated.
--
Kevin
