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>
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.
Serge
----- Original Message -----
From: "Stanley,Michael P." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 26, 2001 12:34 PM
Subject: MailetConfig
> I've been reading James code for the last several days (I've even begun
> drawing up some UML to help get better understanding of it). Just to
> begin I would like to say that this is a great project, and I am excited
> to offer my help. I will be putting in some time to help with this
> project.
>
> It seems that MailetConfig is implemented in the very core and has only
> one implementation 'INLINE'. This seems to be good for most mailets
> that are used, however I can forsee it leading to problems and I also
> think that this approach almost wastes the abstraction of having a
> MailetConfig interface. And the way it seems to be implemented is that
> you choose an implementation and it is for all mailets.
>
> Ok, to get to the point, I am suggestioning maybe there would be a way
> to allow each Mailet to choose how to implement its configuration.
> (i.e. INLINE, EXTERNAL (in a another file), JDBC, JOHNNY_X, etc). Why
> do I think this is important? Say you have a Mailet that gets repeated
> (i.e listserv) and its configuration starts getting long, this could
> potentially could make a config.xml file unreadable. Now if each
> listserv was able to point to an external file for its configuration
> this wouldn't be the case. There are two ways to approach this, the
> listserv could add a configuration child file that knows where to look
> or it can benefit from a more global abstraction where the deployer has
> the freedom to choose its configuration.
>
> Proposed possible approach.
>
> when I mailet is entered in config.xml it could look something like this
>
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager">
> <configFile>[EMAIL PROTECTED]</configFile>
> </mailet>
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager" config="INLINE">
> <membersPath> file://var/users/list-james </membersPath>
> </mailet
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager" config="EXTERNAL">
> <configFile>[EMAIL PROTECTED]</configFile>
> </mailet>
>
> This shows how the Default config is INLINE so this won't break existing
> structures.
>
> What are peoples thoughts on this? I would like to here some opinions
> before attempting patches.
>
> Mike
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
