Mailing List Archive

My preference is that we do this for 2.1. We still need to do some more
bugixing in 2.0 (the Mozilla behaviour for instance) and some
optimizations (see if we have queries that can be optimized or done away
with)

Changing dbmail-adduser will probably not break to much. Can't we
program it to accept the same syntax as now, plus all the sane features
it should have?

Ilja

Aaron Stone wrote:

> Hey,
>
> So I was looking at dbmail-adduser today, trying to remember how to use the
> crazy thing... and I'd like to scrap the current command line interface and
> replace it with something clean and GNU-ish, using getopt, and without crazy
> position dependent overloaded single characters.
>
> Since I'm sure a lot of people might already have scripts to control
> dbmail-adduser, would you prefer if I rewrote the command line in time for
> 2.0, or would you not mind if it changed dramatically between 2.0 and 2.1?
>
> Aaron
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev

Well, I would like to see a new command 'dbmail-user' where an administrator can
add, delete, or modify the attributes (quota/aliases) of a user.

Then write a wrapper called 'dbmail-adduser' that operates the same as the current
'dbmail-adduser' but calls the new 'dbmail-user' to do the work.

But yes, this is a v2.1 operation since the functionallity of 'dbmail-adduser' would
not change.

ed

On Thu, 11 Mar 2004, Ilja Booij wrote:

> My preference is that we do this for 2.1. We still need to do some more
> bugixing in 2.0 (the Mozilla behaviour for instance) and some
> optimizations (see if we have queries that can be optimized or done away
> with)
>
> Changing dbmail-adduser will probably not break to much. Can't we
> program it to accept the same syntax as now, plus all the sane features
> it should have?
>
> Ilja
>
> Aaron Stone wrote:
>
> > Hey,
> >
> > So I was looking at dbmail-adduser today, trying to remember how to use the
> > crazy thing... and I'd like to scrap the current command line interface and
> > replace it with something clean and GNU-ish, using getopt, and without crazy
> > position dependent overloaded single characters.
> >
> > Since I'm sure a lot of people might already have scripts to control
> > dbmail-adduser, would you prefer if I rewrote the command line in time for
> > 2.0, or would you not mind if it changed dramatically between 2.0 and 2.1?
> >
> > Aaron
> >
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

Security on the internet is impossible without strong, open,
and unhindered encryption.

Ilja Booij <ilja@ic-s.nl> said:

> My preference is that we do this for 2.1. We still need to do some more
> bugixing in 2.0 (the Mozilla behaviour for instance) and some
> optimizations (see if we have queries that can be optimized or done away
> with)

Perhaps we should set up the version numbering like the Linux kernel;
version 2.1 will be a development series and 2.2 will be stable again.
There's a lot of stuff that we're holding for 2.1 and I'm concerned that
we'll need a lot of development releases to get them tested and stabilized.

> Changing dbmail-adduser will probably not break to much. Can't we
> program it to accept the same syntax as now, plus all the sane features
> it should have?

Unfortunately, getopt would choke hard on the current syntax. I'm probably
not going to be nearly as helpful with debugging the IMAP stuff as I have
been with the delivery, LMTP and general weirdness stuff, so I'm hoping to
help clarify and improve upon other parts of the system.

> Ilja
>
> Aaron Stone wrote:
>
> > Hey,
> >
> > So I was looking at dbmail-adduser today, trying to remember how to use
the
> > crazy thing... and I'd like to scrap the current command line interface
and
> > replace it with something clean and GNU-ish, using getopt, and without
crazy
> > position dependent overloaded single characters.
> >
> > Since I'm sure a lot of people might already have scripts to control
> > dbmail-adduser, would you prefer if I rewrote the command line in time
for
> > 2.0, or would you not mind if it changed dramatically between 2.0 and
2.1?
> >
> > Aaron
> >
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--

Oh, that's an interesting thought. Makes a lot of sense except that it
leaves a layer of cruft in that the dbmail-adduser wrapper would have to
still use the awful command line syntax now in place :-\

dbmail-user could be one of those binaries that has different default
behaviour depending upon argv[0], which is the progam name as called. Call
it dbmail-user and it has no default mode. Call it dbmail-adduser and it
wants to know who to add. Call it dbmail-deluser and it wants to know who to
delete. Like gzip/gunzip, though, a command line flag could use any of them
for any function, however.

Aaron


""Ed K."" <ed@hp.uab.edu> said:

> Well, I would like to see a new command 'dbmail-user' where an
administrator can
> add, delete, or modify the attributes (quota/aliases) of a user.
>
> Then write a wrapper called 'dbmail-adduser' that operates the same as the
current
> 'dbmail-adduser' but calls the new 'dbmail-user' to do the work.
>
> But yes, this is a v2.1 operation since the functionallity of
'dbmail-adduser' would
> not change.
>
> ed
>
> On Thu, 11 Mar 2004, Ilja Booij wrote:
>
> > My preference is that we do this for 2.1. We still need to do some more
> > bugixing in 2.0 (the Mozilla behaviour for instance) and some
> > optimizations (see if we have queries that can be optimized or done away
> > with)
> >
> > Changing dbmail-adduser will probably not break to much. Can't we
> > program it to accept the same syntax as now, plus all the sane features
> > it should have?
> >
> > Ilja
> >
> > Aaron Stone wrote:
> >
> > > Hey,
> > >
> > > So I was looking at dbmail-adduser today, trying to remember how to
use the
> > > crazy thing... and I'd like to scrap the current command line
interface and
> > > replace it with something clean and GNU-ish, using getopt, and without
crazy
> > > position dependent overloaded single characters.
> > >
> > > Since I'm sure a lot of people might already have scripts to control
> > > dbmail-adduser, would you prefer if I rewrote the command line in time
for
> > > 2.0, or would you not mind if it changed dramatically between 2.0 and
2.1?
> > >
> > > Aaron
> > >
> > > _______________________________________________
> > > Dbmail-dev mailing list
> > > Dbmail-dev@dbmail.org
> > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >
>
> Security on the internet is impossible without strong, open,
> and unhindered encryption.
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--

> My preference is that we do this for 2.1. We still need to do some more
> bugixing in 2.0 (the Mozilla behaviour for instance) and some
> optimizations (see if we have queries that can be optimized or done
away
> with)

Along the lines of optimized queries/indexes, and while the
delivery chain is under development, the unique_id in every index
issue could/should be addressed. I couldn't find my past message
in the archives on the issue offhand, but from what I remember, the
only reason the unique_id was in every index was that in some places
the messages.status column was used to mark a message being inserted,
and in other places an empty unique_id was used for the same purpose.
With a unified delivery chain, it'd be easy to make it always use
the status flag (or whatever mechanism is currently in place) and
drop the "AND unique_id!=''" from almost every query that involves
messages, and then drop unique_id from every index but the one
that's actually supposed to cover it.

caveat: I've not looked at the 2.0 code, it's possbile this has
already been done. :)

Jn



--
Jesse Norell

administrator@kci.net is not my email address;
change "administrator" to my first name.
--

In fact, there are 12 queries which still check for unique_id != '' (or the
similar <> ''); 10 in db.c and 2 in dbsearch.c.

Off the top of my head, I can't think of any time during the message
delivery that the unique_id field should be empty without a corresponding
indicator in the status column... [starts grepping db.c]

Ah, got 'em:

db_imap_append_msg() first inserts without a unique_id but with a valid
status (value of 1, meaning read).

db_copymsg() does some weird stuff, first inserting with 'dummy' and then
using its own algorithm to generate the new unique_id.

Aaron


"Jesse Norell" <jesse@kci.net> said:

>
>
> > My preference is that we do this for 2.1. We still need to do some more
> > bugixing in 2.0 (the Mozilla behaviour for instance) and some
> > optimizations (see if we have queries that can be optimized or done
> away
> > with)
>
> Along the lines of optimized queries/indexes, and while the
> delivery chain is under development, the unique_id in every index
> issue could/should be addressed. I couldn't find my past message
> in the archives on the issue offhand, but from what I remember, the
> only reason the unique_id was in every index was that in some places
> the messages.status column was used to mark a message being inserted,
> and in other places an empty unique_id was used for the same purpose.
> With a unified delivery chain, it'd be easy to make it always use
> the status flag (or whatever mechanism is currently in place) and
> drop the "AND unique_id!=''" from almost every query that involves
> messages, and then drop unique_id from every index but the one
> that's actually supposed to cover it.
>
> caveat: I've not looked at the 2.0 code, it's possbile this has
> already been done. :)
>
> Jn
>
>
>
> --
> Jesse Norell
>
> administrator@kci.net is not my email address;
> change "administrator" to my first name.
> --
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--