RE: specifying ODBX DSN

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Thu, 4 Mar 2010 15:05:08 -0800

> -----Original Message-----
> From: opendkim-dev-bounce_at_lists.opendkim.org [mailto:opendkim-dev-
> bounce_at_lists.opendkim.org] On Behalf Of Mike Markley
> Sent: Thursday, March 04, 2010 2:08 PM
> To: opendkim-dev_at_lists.opendkim.org
> Subject: specifying ODBX DSN
>
> opendkim-db.c seems to require DSN datasets to be formatted as:
>
> dsn://...
>
> While the comments and parsing for DKIMF_DB_TYPE_DSN seem to expect
> that
> the URI scheme will be the DSN backend (e.g. pgsql://... or
> sqlite3://...).
>
> I admit that I haven't tested the DB stuff at all, and at this rate
> maybe it just ships and any issues therein get fixed in 2.0.1. With
> that
> said: am I misunderstanding the current code, or is this an actual
> issue?

It's actually:

dsn:pgsql://... (for example)

Our code takes the data set name up to the first colon to determine which handler to use (i.e. which type it is) and passes the rest to the handler's "open" code.

But this brings up an inconsistency in that the "open" code for OpenLDAP actually does use the whole string, keying on "ldap", "ldaps" or "ldapi" to select the opener but not dropping it from what gets handled. I did this because LDAP connections are widely specified as URIs already, so it seemed an easy integration step.

To be consistent about it, I could take any OpenDBX scheme before the colon and pass that to the OpenDBX handler. Then only "file", "db", "csl" and "refile" would be special and handled internally, and the rest get routed to specific extension libraries. Doing so would require a hard-coded list though since there's no way to get the list of supported backends from their API.

I'd say this is a 2.1.0 thing at this point, unless someone feels doing so at that time would cause a huge headache. (And we could always teach our stuff to just ignore "dsn:" for a while.)
Received on Thu Mar 04 2010 - 23:05:17 PST