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