Paul J Stevens <[EMAIL PROTECTED]> said:
[snip] > Actually, some kind of UML redesign would really help
> cleanup the code base (_ic_fetch, aarrrgh) and provide a better handle for
> developing modules such as this. I know Dan was blasted for suggesting this,
> but I happen to agree with him on this one. Dbmail is *not* too small for
> well formed design patterns.
I did much of the UML blasting because although the goal -- better
modularization and structure -- is good, I don't think that UML is the
right tool for us. I'm particularly weary of over-modularization, I've
seen way too much code where someone thinks that because you've wrapped
incredible complexity into three lines of super high level calls, that the
program is clean and efficient ("Well it's just three lines of code,
right?").
> Records like the DBMAIL_DELIVERY_USERNAME should exist in the sql tables
> only, right? I don't see the point of having such a user exist in the ldap
> database.
Yes, exactly. I've been wondering for a long time how to handle this. I
was hoping to simply leverage the pluggable database layer to also wrap
the auth functions, so that authldap->get_userid could make calls to
authsql->get_userid to use the database as a secondary authentication
source.
> These can all be renamed and moved to auth/.. quite straightforwardly. Of
> course they require reimplementation in the ldap layer.
So basically put some sql queries into authldap? Sounds fine to me.
> I agree with your suggestion about delaying this for the 2.1.x development
> series (assuming we assume linux kernel style numbering from now on...)
If LDAP is entirely broken right now, we should fix it before 2.0, if it
requires major changes to the interface. If it's just adding code in a few
places, maybe we can justify it as point release severity and fix it
during the 2.0.x series.
> Unless Aaron (our most experienced ldap developer it seems) puts his weight
> behind this, I don't see us finishing this any time real soon. Even though
> I'm aching for ldap support :-(
I do have time to work on this in the next week or two, so if, as I oh-so
subtly suggested, save LDAP work until RC9, then I think we can do it.
Let's not hold off on today's RC8 just because of LDAP, we have tons of
other features and database migrations and so on to get tested and
straightened out, and the sooner the better on those.
Aaron
--
