On Mon, Feb 23, 2009 at 1:19 PM, Jared Johnson <jar...@nmgi.com> wrote:
>
>> What kind of locking and/or transactioning do we want in persistent notes?
>
> I suggest letting the backend handle both. Typically we'll be using
> something that was designed to let not just multiple QP processes but also
> multiple non-QP processes interact with the store, and so it already has to
> implement its own locking and atomicity. If we absolutely need to implement
> our own, we can do so in the plugin.
>
> -Jared
I meant, specified by the client. Letting the needs and
compatbilities work themselves out organically works, of course, but
there is little gained over letting plugins that want persistence do
it themselves.
What about making a tiehash interface for notes, instead of the
dual-call interface? Wrapping the dual-call interface in tiehash
sugar will be easy:
package Qpsmtpd::connection::notes::tie;
sub TIEHASH{
shift; # lose package
my $self = shift;
bless \$self
}
sub FETCH{
${$_[0]}->qp->connection->notes($_[1])
}
sub STORE{
${$_[0]}->qp->connection->notes($_[1], $_[2])
}
__END__
and standard plugin configuration parameters could include what
packages (and tie parameters!) to tie persistent (and non-persistent!)
notes to.
--
If I drink much more coffee I'm going to be able to fish the ceiling.
