On 2007-09-25, at 1836, Rick Widmer wrote:
The difference between shared and static libraries isn't in the code. It is all compiler options and when the linking actually happens. The problem as I see it is ./configure options like -- enable-clear-password. This option changes the table definition in sql back ends, and the structure of the vpasswd and vpasswd.cdb files in the cdb back end. It may even change the struct that contains the password data.
not an issue... make the SQL tables HAVE that field, as a varchar() which allows NULL, and leave the item in the struct, so that the only difference between "with" and "without" clear passwords is whether or not those fields in the SQL table or vpasswd file are used or not. basically if clear passwords are NOT supported, then we would always store NULL or an empty string in those fields.
The solution as I see it is to compile with everything on, disable undesired options at runtime based on the configuration file, and always provide variables and fields, even for disabled items, when library functions are called.
err... yeah, what he said.
my suggestion would be to use 5.5 as the "testing ground" as we migrate closer to a single API and a shared library, with 6.0 being the "release" with a shared library only.OK, I won't start anything yet... I am partial to 6.0 being dev and 6.1 being stable. If we unify the library interface and change the database structure it is a major change.
usually the "stable" versions have even sub-version numbers (i.e. for the linux kernel, 2.3 and 2.5 are experimental, while 2.4 and 2.6 are stable.) maybe start a 5.9 as the test-bed for what will eventually become 6.0?
i also have an idea which has been suggested, in various forms, by several users... a field in the vpasswd file and/or whatever SQL table serves its function, for a timestamp when a particular password was set, and one which, if non-zero, will "expire" a password. this allows for "aging" schemes to be built- some companies have policies which require users to change passwords every 90 days or whatever, and right now vpopmail has no way to support this.
i also wonder if it wouldn't make sense to change the format of the vpasswd file itself- instead of fields separated by ":" with each field having its meaning based on its ordinal number within the line, how hard would it be to support the "userdb" format- fields separated by "|", and each field being of the format "name=value"... i would imagine the code to parse this format already exists somewhere, it would just be a case of moving it into vcdb.c. this would allow extra fields to be added in the future without any major code changes.
i think if we're going to start designing a major new version, now is the time to make these kinds of major changes.
---------------------------------------------------------------- | John M. Simpson --- KG4ZOW --- Programmer At Large | | http://www.jms1.net/ <[EMAIL PROTECTED]> | ---------------------------------------------------------------- | http://video.google.com/videoplay?docid=-1656880303867390173 | ----------------------------------------------------------------
PGP.sig
Description: This is a digitally signed message part
