Milter-greylist

I've been reading this for a while, and I looked on the web page that one 
of the items on the ToDo list is: "Add database back-ends. SQLite is a 
good candidate."

Is anything like this happening? Will it ever? This in my opinion would be 
the jump point for the milter to become really huge. It seems really easy 
to implement. What's happening?

-- 
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

Steven W. Orr <steveo@...> wrote:

> Is anything like this happening? Will it ever? This in my opinion would be
> the jump point for the milter to become really huge. It seems really easy
> to implement. What's happening?

Nobody did the work yet, and developement is stalled until the 3.0
release anyway,

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

At Wed, 15 Nov 2006 22:55:25 +0100,
manu@... wrote:
> 
> 
> Steven W. Orr <[[steveo@...]]> wrote:
> > Is anything like this happening? Will it ever? This in my opinion would be
> > the jump point for the milter to become really huge. It seems really easy
> > to implement. What's happening?
> Nobody did the work yet, and developement is stalled until the 3.0
> release anyway,

I'm now developing Berkeley DB backend. Design goals:
* Transactional protection
* Consistency after configuration changes, particularly lazyaw and
subnetmatch
* Extendible DB format

AIDA Shinra <shinra@...> wrote:

> I'm now developing Berkeley DB backend. Design goals:
> * Transactional protection
> * Consistency after configuration changes, particularly lazyaw and
> subnetmatch
> * Extendible DB format

Some time ago, I added support for Berkeley DB, but I gave it up since I
could have no integrity garantee in case of unclean shutdown. 

The way it currently works, we dump the new database in a temporary
file. Then use rename(2), which on many system garantee that either the
old or the new file will exist, even in case of a power failure during
the system call.

Moreover, if you are developing stuff, you might want to patch against
upcoming 3.1.1. I maintained it for weeks, and it has your race
condition fixes plus all the fixes that were submitted for 3.0rc.

Speaking of this, I think it's high time to roll out 3.0 and 3.1.1. If
someone has a fix for 3.0rc7, it would be nice to submit it right now.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

At Thu, 16 Nov 2006 08:55:04 +0100,
manu@... wrote:
> 
> AIDA Shinra <[[shinra@...]]> wrote:
> > I'm now developing Berkeley DB backend. Design goals:
> > * Transactional protection
> > * Consistency after configuration changes, particularly lazyaw and
> > subnetmatch
> > * Extendible DB format
> Some time ago, I added support for Berkeley DB, but I gave it up since I
> could have no integrity garantee in case of unclean shutdown.

Transaction ensures integrity with much less cost.

> The way it currently works, we dump the new database in a temporary
> file. Then use rename(2), which on many system garantee that either the
> old or the new file will exist, even in case of a power failure during
> the system call.
> Moreover, if you are developing stuff, you might want to patch against
> upcoming 3.1.1. I maintained it for weeks, and it has your race
> condition fixes plus all the fixes that were submitted for 3.0rc.
> Speaking of this, I think it's high time to roll out 3.0 and 3.1.1. If
> someone has a fix for 3.0rc7, it would be nice to submit it right now.

Don't worry, I'm not a quick coder. :-) Even if my first patch were
posted before 3.1.1, the implementation will be almost independent
from other components.