Casey Allen Shobe wrote:

First, this is getting pretty far off the topic for this list, it might
be good to move to  [EMAIL PROTECTED]  the official
list for vpopmail development.

On Tuesday 19 July 2005 16:14, Charles J. Boening wrote:

How about making [a default .sql schema] and submitting it?

I plan to as part of my work.

One thing you need to worry about, there are currently two strategies
vpopmail users for storing domains.  One has one table per domain, the
other puts all domains in a single file.  The first would be pretty hard
to do with a .sql file because you don't know the table name until you
create a domain.  I was hopeful we could eliminate the one table per
domain setup, but just found out Qmail Rocks suggest that as the
standard setup. :(

I would like to see a third strategy with a more relational database.
For example there would be a table for domains with all domain related
data (limits) in it, and another table for addresses/users.

Pure-FTPd integrates nicely with our database using a view which is the only thing the pure-ftpd user can read. mod_auth_pgsql for apache also works well in the same manner. This is the approach I had in mind originally before you brought up efficiency problems of reading configuration files.

I very much like the vpopmail way of compiling settings into the
program.  It is a little more hassle to change your configuration, but
it really files on a heavily loaded server.

I guess the direction that could be taken with vpopmail is to
abstract the database layer and let the user define how the data
is stored and returned.

Yes, but while the way that pure-ftpd and mod_auth_pgqsl work is handy, it's completely unecessary for postgresql like it is for mysql, because postgresql supports stored procedures and views, so one could simple customize them instead of customizing a configuration file. I don't think having the procedure and view names hardcoded would be a bad thing, as I said before, and would be more efficient.

I don't think you will find much support for you changes if you are too
radical.  What ever you do will need to be reasonably compatible with
MySQL and the other databases vpopmail supports.  I would like to see an
abstraction layer that hides the differences between databases in one
group of files, and various query strategies in another group.  I have a
good chunk of the first that handles MySQL and postgreql.

The second will be needed now that I realize that there is no way to
make one table per domain go away any time soon.

One could continue this to include things like runtime
configuration of logging options.

I think this is better handled with an extra configure option, I think --enable-mysql-logging already exists.

--enable-mysql-logging went away very recently.  It is replaced with
--enable-sql-logging, because we want all the database back ends to work
the same way.

I seem to recall on the list someone talking about a vpopmail

Well it's completely unecessary with the stored procedure approach because then the "configuration" (which lies inside the stored procedures and views) is already stored in a daemon (postgresql). I don't think I really like the idea of vpopmail becoming a daemon, come to think of it.

The vpopmail daemon is used to allow programs other than qmailadmin,
possibly running on machines other than the web server to provide
functionality like qmailadmin.  It is basically an interface to the
vpopmail command line programs, but at a lower level.

Doesn't matter.  If you create views and tables in your database
to match what vpopmail needs, then you're all set.  I don't think
it matters if vpopmail officially works off of views, stored
procedures or tables.

Well except you can't update a view. I didn't look that extensively at how vpopmail handled the vpopmail (and other) tables where writes were performed as well as reads...and assumed that it needed an object with the expected columns that behaved exactly like a table (it could select, update, delete, or insert). This may have been a wrong guess on my part, but I don't have time to look at the code again just now (will later though).

Again, I expect you will run into great resistance if you try to do
things that can't be handled by the other databases vpopmail supports.

As far as database writes they are mostly done when you add or modify
accounts.  The only exceptions I can think of off the top of my head are
recording the last login information, and logging.

For account management, you will definitely need to be able to insert
delete and update records in various tables.  Right now the table
structure is kind of messy, but that is what the installed base is
running with.

Exactly why I said "extra features" above (okay so I said "certain features" first, but what I meant was "certain optional features". Optional features that require additional database support (i.e. clearpasswd, db-logging, etc.) would best be handled by default with additional tables rather than additional columns.

Personally, I wouldn't object to having all fields in the table, and the
program can ignore those that are not needed.  Again the key point will
be backwards computability.

How often do you change hostname, database, username and
password?  I don't change mine very often.  If I do it would
probably just be the password.

It's a matter of administration. I can't reasonably compile these values in, because I want to use my distributions package management to install new releases of vpopmail, and just maintain a common configuration across them.

I believe the database credentials have been moved to an external file
for MySQL and Postgresql.  It certainly has for MySQL, which suggests it
should be added to Postgresql if it isn't there already.  (Much as I
dislike the idea of having to open that additionsl file every time a
message is delivered, or a user logs in.)

The multiple host is where I see an issue coming in.  I don't
believe vpopmail has support for multiple postgresql database

Well, I'm personally not too concerned about this as we use DRBD, but it would be nice to add at the same time for other users' setups, perhaps.

The code for multiple database servers is in the MySQL back end, and can
be ported to Postgresql fairly easily.  The missing link is lack of
replication in Postgresql, I believe.  In MySQL read only queries are
sent to the slave server(s), and write queries are sent to the master.
MySQL handles updating the slaves when the master is updated.

I think I have this pretty well sorted out in my head now, the next step is just to hack it together and submit a big patch I suppose - that's probably when people will come out of the woodwork complaining about it. :P

Two words....  Backwards Compatibility!  I'm pretty sure a radical
change that can't be duplicated with the other databases will be rejected.


Reply via email to