Re: [siesta-dev] Config committals

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

From: Simon Wistow
Subject: Re: [siesta-dev] Config committals
Date: 00:14 on 04 Sep 2002
On Tue, Sep 03, 2002 at 11:06:09PM +0100, Richard Clamp said:
> 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.

Thassa one. I wasn't exactly sure of the right way to do things. 
> No, configuration is a property of an objects, not a full-blown object
> in its own right.

Good point. So what should actually happen is something like 

	$plugin->set_config('key', 'value');

Where Plugin is an instantiated object that extends Siesta::Plugin.

> 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.

Cool. So basically the API above is ok?

So how do we want to store it? A single Config database table with a 'type' key
or we could just have basically have a table with 

	namespace, user_id, list_id, key, value

and we know it's a per-user then only user_id will be set and if it's per-list
then only list_id will be set and if it's a per_user_per_list then both will be
> They're even stored in the same database instance[0].
> [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.

Yeah. Ima::DBI is nice in a way but a huge hack in other ways. I never really
felt comfortable with it. Happy to get rid of that.

Sorry, like I said I didn't mean to sound snippy. Tired and a bit stressed. And
this fr&^king net connection keeps dropping.

I'll change the code tomorrow.


There's stuff above here

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