Serge Knystautas wrote:
>
> First of all, thanks! All support is greatly appreciated. If you can, I
> think the UML you've drawn up could help other developers trying to get a
> handle on the code.
>
> As for the external configuration, I agree the flexibility would be nice.
> I'm not sure on the syntax though. I would prefer to have an attribute on
> the mailet element indicate where the alternate configuration comes from,
> i.e., I think it is confusing to have a nested element dictating
> configuration information in the same place you would otherwise specify
> inline parameters.
>
> So instead what about something like...
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager"
> config="file:[EMAIL PROTECTED]">
> </mailet>
>
> or I might even suggest putting not only the mailet configuration, but the
> mailet class and match in as well. e.g.,
>
> <mailet config="file:[EMAIL PROTECTED]">
> </mailet>
I would also like to see a slight shift in terminology. Mailets can be
used by different matchers in different processors, so calling the xml
element mailet is a bit confusing.
I'd prefer something like (for external config)
<stage name="MyStage" config="file:[EMAIL PROTECTED]">
</stage>
and for inline config, instead of:
<mailet match="RemoteAddrNotInNetwork=127.0.0.1,192.168.1"
class="ToProcessor">
<processor> spam </processor>
</mailet>
have:
<stage name="StopOpenRelays" config="INLINE">
<match class="RemoteAddrNotInNetwork">
<allowedNetworks="127.0.0.1,192.168.1"/>
</match>
<mailet class="ToProcessor">
<processor> spam </processor>
</mailet>
</stage>
This is slightly more verbose in the config but less confusing, I think.
It also allows log messages to specify exactly which use of a mailet or
matcher is reporting something.
and, it gives us more flexibility going forward, in case, e.g. someone
comes up with boolean matchers or multiple mailets per match.
> Just off the top of my head. Someone a few months ago was asking about how
> to configure a processor dynamically (in your words, externally instead of
> inline). For instance, rather than creating 10 lines for 10 listservs in
> the xml conf file referencing an external configuration, have a single
> element reference an external configuration that would configuration 10 (or
> however many) mailets for a dynamic list of listservs.
>
> If we could accomplish both these wishes in one approach, I'd prefer that.
>
> All of this also gets slightly more complicated because James doesn't know
> how to reload the configuration without a restart. Right now, the external
> source could change, and James wouldn't know to take effect. This may or
> may not be desirable.
One factor is getting James to restart - or more accurately reconfigure
the spool manager block. This should be handled by a Phoenix service but
I'm not sure how.
The second is that Avalon/ Phoenix has (I think) a Camelot system for
containers so that mailets could be like WARs in a servlet container.
That could be cool, but might be a lot of work.
Good luck,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
