On 2007-09-25, at 0513, Rick Widmer wrote:
Joshua Megerman wrote:1) A shared library with a stable API would make recompiling outsideprograms (e.g., QmailAdmin) unnecessary, which would be a Good Thing(tm).It is that 'stable API' that is the killer. I know some ./ configure options change the interface to libvpopmail. I don't know which ones they are. :( I do know if you change some of the options you can get some spectacular failures if you forget to re- compile everything that uses vpopmail.
maybe we need to change the API, standardize it... if there are functions which either "do" or "do not" need an extra parameter, then i would say to add that parameter anyway, and if the final program doesn't use it, it can pass a 0 or NULL or whatever, and the function would ignore it.
Once upon a time vpopmail was designed to be quick and tiny. All options were compiled in. Since then at least 3 of the back ends have adopted a configuration file. Maybe it is time to look at moving most of the ./configure options to a configuration file
add a vpopmail_init() function which reads that file and sets a bunch of "use_*" variables, which the other functions would then check. make it a requirement that all client programs must call this function first, or any functions whose operation depends on these variables being properly set, could call this function instead... of course it would have a flag variable so that calling it multiple times doesn't result in the config files being read multiple times, something like this...
int flag_init = 0 ;
int use_auth_mysql = 0 ;
int use_auth_pgsql = 0 ;
int use_auth_ldap = 0 ;
int use_auth_sybase = 0 ;
int use_onchange = 0 ;
void vpopmail_init(void)
{
if ( flag_init ) return ;
/* read the config file, set all use_* vars
if we encounter errors, exit(1) */
}
we also need a "reinit()" function, so that processes like vpopmaild
can force the config to be re-read without having to be stopped and
restarted.
void vpopmail_reinit(void)
{
flag_init = 0 ;
vpopmail_init() ;
}
and of course, the relevant functions need to check these variables
in order to work properly. for example, i know the call_onchange()
function is already written to early-exit if the ~vpopmail/etc/
onchange script doesn't exist or isn't executable, it would be
trivial to early-exit if the "use_onchange" variable contains a zero
instead of a one.
i think i'm probably being a bit too detailed for this list, this should probably be moved to the developer list.
and have only one vpopmail library interface for the entire life of a major (minor?) version.Are we starting 5.5 or 6.0 if we change the library interface, and table layouts?
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.
the other suggestion i have is this- there are options which make sense for larger systems, and don't hurt anything for smaller systems, the ones involving splitting the domains and mailboxes into numbered sub-directories in order to prevent having a single directory with 15,000 entries in it. these options should just plain be turned on for everybody, and the "options" should be removed.
the only argument i've ever heard for keeping them as options is that some people have written scripts which make assumptions about the directory structure. these scripts should run "vdominfo -d" and "vuserinfo -d" to get the directories, rather than assuming they will be in any particular location. i'm just not a fan of hanging on to options which serve no purpose other than to accomodate improperly written scripts- the idea of splitting the domains and mailboxes into different directories has been around forever, there's no excuse for somebody to not have made the adjustment by now.
---------------------------------------------------------------- | 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
