Aaron Stone wrote:
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?").
So maybe sometimes they were right :-) ? But you do have a point. I
wrote a couple of iterations of an ORB in php some years ago as part of
a cms framework. Only the code I wrote after studying proper frameworks
in python (esp zope and twisted) is still readable/usable. I think I've
come to appreciate some of the design problems involved.
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.
Not all sql calls involving users have to be implemented in authsql.
db.c seems like a pretty good place to me. Like I've stated before; in
my view the auth modules have been bloated beyond authentication. They
now more like represent mappings of the users and aliases structures to
the ldap/sql backend storage. A different beast all together.
These can all be renamed and moved to auth/.. quite straightforwardly. Of
course they require reimplementation in the ldap layer.
I've done this, added stubs in authldap.c, and all is well. Builds just
fine with and without ldap and apps test ok without ldap.
So basically put some sql queries into authldap? Sounds fine to me.
No. Put some db_ calls in authldap, no real sql queries. Those belong in
db.c or authsql.c
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.
I'm not sure its doable if we want a modicum of QA. Also, I want 2.0 out
of the door, so we can start working on a unstable series. We have cvs
access but we can't really use it for development of new features
because of the current freeze. So let's release rc8, branch 2_0_branch
as a starting point for rc9, 2.0.0, and beyond, and open the head branch
for actual further development of all these new features.
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.
right.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
