Aaron Stone wrote:
Thanks for getting into the Wiki thing, it's the best way to keep track of
what happens through a mailing list discussion.
OK. I promise I won't overdo it :-)
On Wed, Apr 20, 2005, listmember <[EMAIL PROTECTED]> said:
[snip]
A lot of the stuff that has been clumsy to do in IMAP can be easily
handled by a good enough RDBMS --I am biased towards PostgreSQL and
Firebird/Vulcan.
[yank]
I just hope that you guys have glance at those pages and incorporate
some of the ideas into the infrastructure --clients will follow.
I strongly disagree with tying DBMail too tightly to any particular
database. I know that MySQL < Perfect (TM), but it's popularity builds our
popularity. Add to that the fact that MySQL is growing features at about
the same rate as we're able to build them into DBMail, and the
relationship is golden.
Oh boy, I was prepared for almost for anything else but never an
RDBMS falmewar :-)
When I said I am biased towards PostgreSQL and Firebird/Vulcan, I did
not mean it to be an authoritative view --just a personal one.
And that view was not meant to imply that DBMail should be tied to
any particular DB --indeed, it should not be.
I'm not making a MySQL specific defense though; the same goes for SQLite
and all sorts of other backends we might eventually use.
Fair enough.
The best database integration will really come only when half of DBMail is
written in stored procedures. But then we're joined at the hip to a
dababase system, and porting to others becomes a massive undertaking,
fraught with QA nightmares in terms of testing functionality.
I could'nt agree more; you are absolutely right: SPs do mean just that
--in for life.
But, I don't recall advocating SPs anywhere at all. DBMail is doing
nicely without them, and there is no reason to introduce them rigth
now.
There will be come cases where this is the best or only option, and we can
make provisions for that through weak symbols during linking, function
pointers, etc. All really standard C tricks that will keep us sane and
keep the majority of the backend code common and portable.
Agreed.
Secondly, "clients will follow" -- oh no they won't. Wanna get left out in
the dust? Easy: create your own standards and be the only one to support
them. If the protocol isn't standardized and/or reasonably well known and
implemented, then it's probably not something we want to touch with a 10
foot pole.
No, no... I don't mean creating your own standards as such. What I am
saying is, use /their/ standards --and feed them the information they
need in their standards. As far as Thunderbird is concerned, the
integration means writing an XPI.
[paste]
Auto Replies, Auto Notifications, Mail Client Settings,
Blacklisting and Message Filters are --IMHO-- just some of those
things that DBMail can do much more effectively than other
conventional Mail Servers.
Auto Replies & Auto Notification: good ideas to work on.
Mail Client Settings: custom protocols bad. See
http://asg.web.cmu.edu/acap/ for just how nasty something like this can
get even when they are standardized.
Yes. We all know ACAP -Application Configuration Access Protocol.
The wholly grail that never materialized...
If you looked at http://asg.web.cmu.edu/acap/acap-ietf-docs.html
you'd be justified for the prejudice :-)
They were trying to do too much too soon... What I am not asking
for is nowhere near what they were trying to solve.
All we need is some an extension on the client that talks to
DBMail (which in turn talks to RDBMS), or the extension itself
talks to RDBMS itself. No big deal, is it?
Blacklisting: not sure if this should be MTA level.
I am not referring to systemwide blacklisting --simply user
level one.
I have been using fastmail.fm for ages and I can't tell you how
convenient that feature is --for there is always enough nuisance
mails that are not technically spam. Getting rid of them in the
MTA is so much more convenient from a users point of view --it also
unburdens the mail admins.
Message Filters: I've separated the term "filter" from "sorting" like
this:
Filters: look for spam, attachments, whitelists, blacklists. MTA level.
Sorting: put into folders, local reject, vacation messages. MDA level.
Technically you're corect. But, client apps do still use 'filtering'
to mean 'sorting'; wouldn't it confuse people.
Your suggested system basically takes each keyword from Sieve and makes it
into a column in the database. We can do this with key/value pairs and
eliminate the billion columns problem. But there's no protocol for getting
these scripts into the database. So you either need a custom protocol
(bad) or a client which directly manipulates the database (limited
usefulness).
As long as DBMail would use the data in that table, you should not
really worry about the /protocol/. Someone can write a web interface
to handle all that.
Incidentally, do we know of any _popular_ clients that support Sieve?
Isn't the 'billion column' :-) thing an extension of perfectinism :-)
I've been dragging my feet on libSieve because I need some help!
I really dont see what is so great about Sieve. Mortal users dont
like it, can't really use it. Just because it is around does it
make it a 'standard'?
At one point there was code for a nifty regex based sorting system.
RegExp... Are we really talking about the same kind of users that
barely understand MS OE or Moz TB.. :-)
In my most humble opinion, Sieve is anti-KISS to the max :-)
