Re: [siesta-dev] Config committals

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

From: Greg McCarroll
Subject: Re: [siesta-dev] Config committals
Date: 19:52 on 03 Sep 2002
* Richard Clamp ( wrote:
> On Mon, Sep 02, 2002 at 04:38:14PM +0100, Simon Wistow wrote:
> > I've just committed a load of stuff that puts a config infrastructure in
> > place.
> Okay, I'm just caught up with my email backlog from the weekend oop
> north and am left with an observation, and a question.
> > Basically you do something like this 
> > 
> > 
> > my $list_config = new Siesta::Config::List($list_id);
> > $list->get('Namespace', 'key');
> > $list->set('Namespace', 'key', 'value');
> > 
> > and the same for user.
> > 
> > however you can also do 
> > 
> > my $list = new Siesta::List($list_id);
> > $list->get_config('Namespace', 'key');
> > $list->set_config('Namespace', 'key', 'value');
> 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.
> The question:  Wuh?

ok, let me state some thoughts,

so, we basically have 3 types of configuration, list,user,listuser yes?

and they have a precedence of, i'm guessing


now each config row has,

	namespace (plugin?)

well there are 3 things, i would do if i was doing configuration, they
are as follows, (these are personal ideas, ymmv),

	1.) get rid of the key/val and introduce a blob with a storable
	    freezed hash in it (this will allow more flexibility in
	    the end, e.g. what happens when a config value needs an
	    @array (such as a list of banned addresses in the subscribe

	2.) amalgamate all config information into one table, with the

		config_type (3 = listuser, 2 = user, 1 = list)

	    get config out with something like (in pseudo SQL)

		select blob 
		where user_id = $
		or    list_id = $
		or    listuser_id = $
		and   max(config_type)

		(i still dont like this as it means doing it 
		 more than once per plugin run)

	3.) use the same mechanism as the rest of the storage for
	    storage, if the storage is far to yucky, fix it, but 
	    at least try and tie in with Storage some how

these are random thoughts, i feel about them least strongly (1) to
most strongly (3)


sorry i havent been more productive, i've been doing paid work and
it has a higher priority due to my fondness of beer and pie


Greg McCarroll               

There's stuff above here

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