Paul J Stevens wrote:
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.
Agreed. Splitting authentication and other user operations should be split.
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
Agreed.
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.
rc8 was released yesterday.
I don't think rc9 have any change in the LDAP work. The code's there,
but we should not advertise it. There's no place in the docs where we
mention it. And we shouldn't, until it works. There is the
--with-auth-ldap configure option, but I've added a warning to that
("don't use, unstable").
I'll branch off dbmail_2_0_branch now, so all new stuff can go into the
trunk, and fixes for 2.0 can go into dbmail_2_0_branch.
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.
Ilja
--
Ilja Booij
IC&S B.V.
Stadhouderslaan 57
3583 JD Utrecht
www.ic-s.nl
T algemeen: 030 6355730
T direct: 030 6355739
F: 030 6355731
E: [EMAIL PROTECTED]
