Re: [siesta-dev] Config committals

[prev] [thread] [next] [lurker] [Date index for 2002/09/03]

From: Richard Clamp
Subject: Re: [siesta-dev] Config committals
Date: 23:06 on 03 Sep 2002
On Tue, Sep 03, 2002 at 10:19:37PM +0100, Simon Wistow wrote:
> On Tue, Sep 03, 2002 at 07:22:52PM +0100, Richard Clamp said:
> > The observation: Now we have two different ways of accessing the list
> > database, one via Siesta::Storage (which is used by the existing
> > Siesta::List and Siesta::User code), and another via the
> > Siesta::Config hierarchy.
> This is true. And it's why I bought it up a while back. But I thought

By a while back do you mean 2002-09-01, or at some point back before
then?  I'd use the CVS logs, but they only work when creation and
checkin match up.

> Basically - as far as I can see it anyway - we do need two types of
> storage which are objects (lists, users etc) and config (key and
> value(s)).

No, configuration is a property of an objects, not a full-blown object
in its own right.

> I'm not sure what to do - in some way I'm with Jwz on this one
> "Now wait, I see two different problems: you need a mail summary file;
> and you need a representation for address books. It's not obvious to me
> that those are anywhere *near* the same problem, or that one should try
> to conflate them and solve them simultaniously. The requirements of the
> two problems seem pretty dramatically different to me. 
> On the one hand, it's a drag to do two different implementations, but on
> the other hand, it's a drag to have one of the two problems be solved
> badly because of baggage from the other problem; or to have the
> all-singing-all-dancing solution take longer than two independent
> solutions together."
>                                    - 

On this JWZ isn't talking about our system.  We have a representation
for mailing lists.  An instance of a mailing list has plugins which
are configured.

They're even stored in the same database instance[0].

> The problems of storing Plugin config is not that same as extracting
> Users and Lists from a database. 

10 PRINT "Repetition doesn't make you any more right."
20 GOTO 10

[0] Which incidentally means the new code I just checked in when
cleaning up Storage::DBI will cause yours to die horribly as Isa::DBI
insists on having it's own $dbh, and SQLite only supports one
connection at a time.  Fun Fun Fun.

Richard Clamp <>

There's stuff above here

Generated at 13:56 on 01 Jul 2004 by mariachi 0.52