John Simpson wrote:

On 2006-12-13, at 0211, Rick Widmer wrote:

Extra credit if the addresses are sorted like the /var/qmail/ congrol files so domains sort together.

not unless every single line in the .qmail file is an address.

The way I see it without a sequence field and order by clause you can't depend on the order of entries in a database. Maybe some are, but all it takes is a few deletes and adds and they will find out why they should not be depending on the order of entries...

Since you can't depend on the order now, I see no reason not to go ahead and sort the entries in a way that makes it easy to find the one you are looking for in a list.

If you need the entries to stay in the order you specify you need to be using the new calls that we are designing.

there are cases where program deliveries need to be processed in a specific order- i have one alias, for example, which always delivers to two mailboxes, then runs a program which does a text search, and if certain words are found in the body of the message, delivers to three other mailboxes as well.

I would say that now you are depending on blind luck that these entries stay in order, unless you already have some kind of sequence field. This needs to be done using the new calls, once they exist.

The fun part is making a .qmail/.vpopmail file look like a table. I think it will be easier to efficiently make the file look like a database rather than treating the database like a file.

i'm not sure what you mean here. the format of a .qmail file is defined by what qmail-local understands, because if a .qmail file exists in a domain's directory, qmail-local processes it directly and vpopmail's executables never have a chance to modify how it works (unless the .qmail file contains an explicit call to "vdelivermail".)

Yes, that is one complication, we can't redefine the structure of the .qmail file. On the other hand I absolutely DO NOT want qmailadmin, vpopmaild or any other program built on top of this to have to know what back end is being used. I want to be able to swap out back ends without re-coding higher level programs.

i've always thought the best way to do it was to just add a sequence field to the SQL table containing the aliases, and have "vdelivermail" just duplicate what qmail-local would do if presented with a .qmail file containing the same lines in the specified sequence.

I see two approaches:

1.  Delete all entries, then re-add them in the desired order.

2. Provide a new way to manage ordered sets of data by adding an order field to the functions that add entries.

The first is drop dead easy for cdb, and not all that hard to code for a database, but really sucks for efficiency if you are using a database back end. Its not all that great for the user either.

The second is very easy to code for database, but will be much harder to code the cdb part. I think users would prefer it, I know I do. The extra work to make cdb look like a database for alias updates is "once work." You do it once and forget it.

I think maybe it should look something like:

//  load the cdb file, or BEGIN TRANSACTION on the database
update_alias( alias_name );

//  add an entry at a specific location
add_ordered_alias( alias_name, alias_line, sequence );
//  repeat as needed...

//  write the cdb file, or COMMIT TRANSACTION on the database

Once you 'open' an alias you can do multiple add and delete operations on its lines, with explicit control of the sequence. This provides hooks so you can read the cdb file, manipulate it in memory, and write it out. I also think the commit phase should re-number the sequence fields in a real database so they are always nubered by 10's or 100's so there is room between entries. The cdb files will always be 'renumbered' because there is no place to store the sequence within the file.


Reply via email to