[prev] [thread] [next] [lurker] [Date index for 2002/10/22]
Yes, it's gone quiet again.
Must. Keep. Momentum.
------------------------------
Thought #1 : Per User Config
------------------------------
I've been a bit worried about the idea of User preferences like NoMail,
ReplyTo, Digest and the like.
This should be easy, in theory -
1. mail comes in
2. Per list plugins get called in order (we do that already)
3. We get to the Send part
4. We loop through every user
5. We pass each mail (which no has a user attached) through pipeline
with Per-User plugins in it
Et Voila. Done. I could hack that up now.
But we want to be able to have swappable Send plugins and some of these
might not mail to all users individually but might bunch them up by
domain or something.
This is no problem.
However it means that a generic interface doesn't know what per-user
plugins are activated and that each Send plugin that wants to keep a
list of Per User plugins would have to store it in a preference field.
This means we'd get an interface like this
% nacho set-plugins testlist ReplyTo SimpleSig Send
# allow per list replyto munging, sig simplyfying and then Send
% nacho set-plugin-config-list testlist Send plugins \
"ReplyTo Nomail Digest"
# allow per User configuration of Replyto, Nomail and Digest
That sucks.
Then I hit upon an idea : just have per list user plugins. Whether the
Send plugin decides to use them or not is up to it. The above example
would end up being
% nacho set-plugins testlist ReplyTo SimpleSig Send
% nacho set-user-plugins testlist ReplyTo Nomail Digest
------------------------------
Thought #2 : nacho
------------------------------
The syntax is crufty.
My though was to chnage it to be like this
% nacho set plugins list=testlist plugins=ReplyTo SimpleSig Send
% nacho set user plugins list=testlist plugins=ReplyTo Nomail Digest
the two things is that we'd have to walk a tree to work out what comman
we're doing (not hard) and have key/value pairs for the values although
we could just use gnu style syntax.
The whole
set-plugin-config-default
set-plugin-config-list
set-plugin-config-user
set-plugin-config-userlist
would then become
% nacho set plugin config key=foo value=bar
% nacho set plugin config list=testlist key=foo value=bar
% nacho set plugin config user=simon@xxxxxxxxxx.xxx key=foo value=bar
% nacho set plugin config list=testlist user=simon@xxxxxxxxxx.xxx \
key=foo value=bar
respectively.
------------------------------
Thought #3 : passwords
------------------------------
For the web interface the administrator's going to have to have a
password. And users are going to have to have a password too.
My suggestion is that we have a password field to lists which contains
a hashed admin password and a password field to user which contains a
hashed user password.
These are set to blank by default for users if the user gets added
automatically by something like
% nacho add-user-list foo@xxxxxxxxxx.xxx
but that's their problem isn't it and all the h4XX0r can do is change
their preferences. Quelle Horreur!
------------------------------
Thought #4 : Digests
------------------------------
Just have a cron job that sends a mail down a pipeline that only has
Digest and Send in it. Digets then changes the mail so that it's a
Digets mail?
Or make it so that when a mail comes through the digest plugin decides
whether or not to make a new Digest mail base don something like time or
number of posts that have come through. This is my preferred option.
comments on a postcard to the usual address.
Simon
--
: feel the banana karma
Generated at 13:56 on 01 Jul 2004 by mariachi 0.52