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