Better database??

[Matthias Andree]

On Wed, 03 Mar 2004, michael at optusnet.com.au wrote:

> Unless I terribly misread the code, the datastores actually get passed
> a 12 byte array rather than a struct? (dbv_t *v containing void *data,
> and uint32_t len)

They're being passed abstract data without knowing what they're in for.
You could store an orange marmalade toast if you were so inclined, the
datastore stuff should care even less than not at all.

> What would be even better is to have the datastore's pass a struct containing
> a bunch of function pointers to datastore.c which implements stub functions
> for all functions that aren't filled in.
> 
> I.e. pass 
> {
>         func_t (*set_token)(),
>         func_t (*get_token)(),
>         func_t (*set_robx)(),
>         ....
> } 
> and then datastore can do
>         if (set_robs)
>                 set_robx(new_robx_value)
>         else {
>                 dbv_t x;
>                 x.spam = robx;
>                 set_token(msg_robx_token, &dbv_t);
>         }
> 
> etc etc. Does that make any sense?? After typing all this I'm
> realizing that I should have just implemented it and sent in the patch
> because it would have been clearer and less work. :)

Well, this looks like a layering violation. The datastore* files provide
a data storage service to bogofilter and are at a lower level than
bogofilter's special tokens such as ROBX are - these are in the
application level and should not be known to datastore*.

If you think we need a data abstraction layer that exceeds "cleanup" or
that crosses layering boundaries, please define the two interfaces and
functionality the abstraction layer should provide and what the
advantages are.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95