On Tue, 6 Dec 2005, Jakob Hirsch wrote:
> > You can always preprocess your filter when you edit it - i.e. put it
> > through a kind of "build" process.
>
> Oh yes, nice thing, right. And hope I don't forget to do it everytime..
You build a standard script to do the whole job, like vipw for password
files. And you can also include a syntax check call to Exim in the
script to save you from your typos. But of course, this takes time to
create, even though it may save time in the long run. (This is a
general philosophical point about building tools. Finding time to build
them is difficult in some environments, because it is not immediately
"productive".)
> I already liked the concept of $acl_[cm]_somename more. :)
> As long as the number is farily low, it shouldn't hurt the performance too
> much if we don't use a fancy hashing algorithm, and use a simple linear
> search.
> As I know that you are quite busy (who's not...), I'll probably look into
> that (in the near future), if you don't object to such a change.
I have been sent a patch that extends the number of variables, and a
sufficient number of people have said "yes please", so I was actually
planning on doing it (extending the number of variables). In fact, it's
the next thing on my list of work for the code, but it probably won't
happen till next week at the earliest.
However, I have no plans for named user variables. That is a
sufficiently large new concept that I think it would be a bad idea just
to hack them in as acl variables. A higher-level design that looks at
the whole of Exim is needed.
Note that, because the current variables are numeric, they are stored in
a vector, and so are not only quick to access, but are also quick to
save and restore in the spool file.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
