[tpop3d-discuss] Looking for resources

Chris Travers chris at travelamericas.com
Mon, 26 Jan 2004 21:37:07 +0700


From: "Chris Lightfoot" <chris@ex-parrot.com>
> Yes-- this is in recent releases, enabled with
> --enable-auth-pgsql. The code was contributed by Stephen
> White. (Looks like I forgot to put it in the CHANGES file.
> Oops.)

Yep found it just before I got your email :-P

It isn't in the Readme or the ./configure --help either.

> > Secondly, I wanted to ask:  what sort of features would the community
like
> > to see in this work?  If I am able to make these things work together, I
> > would be more than happy not only to bundle tpop3d with my application
but
> > also contribute these drivers back so that others could use them as
well.
> > What would people like to see?
>
> A database mailbox format is an excellent idea. I
> considered implementing such a thing, but never got round
> to it....
>
> As a general comment, it would be great if you could make
> the mailbox driver as independent of database schema as
> possible. In particular, if you could adopt the same
> substitution-variables approach for SQL queries that the
> auth_... drivers use.
>
I agree.  Here are ways to accomplish this:

1:  Use substitution variables and the configuration file to control how the
mailboxes map to the database interface (the way the auth_mysql driver
works).  Configuration changes I think would require a restart of the pop3
server.

2:  Use a names schema (tpop3d) and a fixed table structure.  One can then
substitute views for the tables, adapting the fixed schema to an arbitrary
database structure.  If the structures change, one can simply reqwrite the
view.  Does not require a restart of any part of the application.

Requires basic schema and advanced view support in a database manager.
Woudl work with Interbase/Firebird or PostgreSQL but not MySQL.

3:  Wrap the interfaces in user-defined functions which could be rewritten
and reloaded without restarting any part of the system.  Would work on
Interbase/Firebird but not MySQL.  It would also eliminate the ability to
use a standard table schema and may impose a performance cost.

I will probably be using solution 2 above, but I may allow for hooks allow
administrators to select alternative queries to run instead.  Nothing wrong
with layering the extensibility ;-)

> What does your database schema for mailboxes look like?

The database schema for mail services is still under development.   Rather
than design a schema that may or may not work, I figured I should take a
look at the various protocols and servers I would need first.  The
requirements are a bit obtuse and complex, and I will not bother you with
them here.

However, I can tell you that the authentication and mailbox views will exist
in a schema named "tpop3d" and will be independent of the actual storage.
Unsure what information will be stored and what information will be used by
pop3d.  But working on it....

Best WIshes,
Chris Travers