[prev] [thread] [next] [lurker] [Date index for 2003/11/18]
On Tue, Nov 18, 2003 at 03:00:35PM -0000, Jody Belka wrote:
> Was just wondering if nacho prevents you from having multiple instances of
> a plugin on a queue just because of how nacho has been written or because
> of something a bit deeper? The table layout looks like it should be able
> to support it, but i'm still figuring out how all of the internals fit
> together so I thought i'd check.
I think it's a combination of hysterical reasons and evolution. The
first iteration of prefs was a screaming mess which pretty much had a
key of plugin.name, list.name, pref.name. With the Class::DBI rewrite
that became the saner plugin.id, pref.name, pref.member key which as
you note would allow for multiple plugins of the same class on the
same list.
It is however quite deliberately coded to only allow one instance of
each class in each plugin queue. That code's in List->set_plugins,
which is tested over in t/09plugin_order.t.
> On a seperate note, I've replaced the 'queues' sub in my Lists.pm with the
> following:
>
> sub queues {
> my $self = shift;
> my %queues = map { $_->queue => undef } $self->_plugins;
> return sort keys %queues;
> }
>
> which seems to be DTRT. is this a sensible change or am i misunderstanding
> something?
Well apart from the mass ugliness, and the hell it'll play with any
::Integration code where the queue could be malformed for the mta it
looks like it would run. Is that your question?
--
Richard Clamp <richardc@xxxxxxxxx.xxx>
Generated at 13:56 on 01 Jul 2004 by mariachi 0.52