If the code is changed to authdb->this() and msgdb->that(), then using two different databases is *not* any more complicated *at all*. Just check the config file, and either open up two libraries or open one and copy the struct.
I'm not enthused by the wrapper functions, can't we just import the symbol db_whatever directly? Granted that means that you'd have to call the libtool dl functions one at a time, it's uglier, imho, to have these wrappers. Aaron Paul J Stevens <[EMAIL PROTECTED]> said: > Allowing people to use different sql backends for auth and storage was > my idea iirc. It was more a logical conclusion following from clean > separation of both code bases - implied by the auth-ldap code, rather > than a serious feature request. > > > Dan Weber wrote: > > On Sat, May 29, 2004 at 08:33:10AM -0000, Aaron Stone wrote: > > > >>This is probably the cleanest way to do it. Renaming all of the function > >>calls to reference struct members shouldn't be too hard. I believe that > >>you could instead load in the symbols for each function one at a time, > >>but then it's not clear that you're working with an external symbol > >>within the code. Since some people also suggested being able to use a > >>different sql database for auth a storage, the struct would make it much > >>easier to separate them. > > > > Having people use a different sql database for auth, adds a lot of > > complexity. I personally don't think it is a good idea. So for > > making compatibility functions, something like this. > > > > int db_check_connection(void) > > foo->db_check_connect(void); > > > > > > > >>Don't forget to define a versioning scheme. The library should export a > >>dbmail_api_version symbol with some kind of major.minor.micro scheme or > >>rev.compat scheme so that before you import the structure with all of the > >>functions you know that it will be the size and signature you're expecting. > > > > > > Good call, that way we can create compatibility versioning scheme. > > > > Dan Weber > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Dbmail-dev mailing list > > Dbmail-dev@dbmail.org > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > -- > ________________________________________________________________ > Paul Stevens mailto:[EMAIL PROTECTED] > NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED] > The Netherlands________________________________http://www.nfg.nl > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
