Hi all,
I have a feeling or worry that since Philip Hazel has retired, Exim may
see much less development and go into a kind of "maintenance mode". I
think it's in danger of falling by the wayside if that happens.
I would be interested to know anyone has plans for future development, in
particular what we might call "exim 5"? I have some wild ideas that I'd
like to throw out there to see what people think. I expect to get flamed
for some of them :) I don't expect them all to succeed, but hope that they
may start interesting discussions.
I like Exim's configuration file syntax, and I propose that we keep it,
broadly speaking, and maintain backwards compatibility as much as
possible.
One small change in the default shipped configuration: in the userforward
router, instead of:
condition = ${if exists{$home/.forward} {yes} {no} }
we could just write:
require_files = $home/.forward
Most of the router drivers don't seem to be strictly necessary any more.
ipliteral is basically unused today, iplookup is not compiled in by
default, and queryprogram, manualroute and dnslookup could be substituted
by expansions in the router options. Routers could then (eventually)
become much simpler, basically having the following tasks:
* run in order
* rewrite address and reinject
* accept with a successful, non-empty assignment to $hosts
* decline with an unsuccessful expansion, an empty assignment to $hosts or
a failed condition
Finally, I think exim's venerable and complex code makes it difficult to
contribute. I also see exim as a kind of experimental/expert/programmable
mail server, allowing us to do things that no other mail server would, but
also full of ancient, inherited quirks.
I'd like to discuss something that could turn Exim into a laboratory and
toolkit for email programming: a complete rewrite in a modern interpreted
language such as Python or Lua, with an object-oriented style, maintaining
feature and configuration file compatibility, and with a test suite.
Existing plugins could be wrapped as native extensions to the interpreted
language, or eventually rewritten as interpreted modules. New plugins
could easily be developed and tested in the debugger of the interpreter.
Of course that last task is a huge one, and while I could contribute to
it, I would not like to do it alone, or to simply hack away at it in my
spare time and present it as a "fait accompli". So I'd like to see if
there's any agreement that this is a sensible way to proceed, and if so
to put together a working group, a roadmap and a division of labour.
Cheers, Chris.
--
_____ __ _
\ __/ / ,__(_)_ | Chris Wilson <chris+sig@???> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |
