Better database??

David Relson relson at osagesoftware.com
Wed Mar 3 05:06:09 CET 2004


On 03 Mar 2004 13:25:30 +1100
michael at optusnet.com.au wrote:

> Matthias Andree <matthias.andree at gmx.de> writes:
> > michael at optusnet.com.au writes:
> > 
> > > [ Little rant: The datastore abstraction layer works in exactly
> > > the wrong direction. The API makes everything look db instead of
> > > presenting the bogofilter data to the datastore in standard way.
> > > argh!!! ]
> > 
> > Care to explain how you'd like the API to look like instead?
> 
> It's not really that bad, I'm just twisted because what I wanted
> to do turned out to be really hard. 
> 
> What I was expecting was a layer that called a datastore saying
> "Here's a token, a spam count, a good count and a date. store them".
> and "Find me the counts and date associated with this token" and
> "Here's the number of messages; Store it". etc etc.
> 
> The idea here is that bogofilter knows exactly what it wants to store,
> and it would be nice if the datastore was told about it. This would
> allow the datastore to use some intelligence in storing it.
> 
> At the moment, the layer does it the other way around: It 
> presents an API to bogofilter and says "I'll store random
> things: Do with me what you will".
> 
> Does that make any sense??
> 
> What I was looking to do was things like to use 16 bit counts for
> storing ham+spam counts; To not store the date; To store the date in
> an imprecise fashion; etc etc. Basically: To take advantage of the
> knowledge of what it is that we're trying to store.
> 
> Michael.

Michael,

Let me see if I can summarize the effect:

Rather than passing a pointer to a struct containing the 3 values, you'd
prefer to pass a trio of values (for writing) or a trio of addresses
(for reading).  Yes?

Ciao,

David




More information about the Bogofilter mailing list