> I also made the decision to put configuration parameters
> into a database.
James can store parameters like these in a db or avalon repository, the
listserve and JDBC alias, mailets do this.
> This obviously has its pros and cons, but
> one big pro is that it unifies the storage of static and
> semi-dynamic parameters. This means for example that given
> a Gemlet that can send an email with to,from and subject
> parameters it also serves perfectly well as a mailing list
> Gemlet and the to or bcc parameter can simply be maintained
> by a subscribe gemlet instead of a web config page. You could
> regenerate XML I guess, but it might be unwieldy if you
> had a few dozen mailing lists with a few thousand members
> being regenerated every time someone subscribes.
> > I think also there will always need to be a 'goto'-like functionality.
> > Specifically, if there's an error in processing... then the
> message go to
> > the error processor.
The difference is that configuration and the actual parameter values are not
necessarily the same thing, in the real world the configuration has to be
written down, preferably in language which is easy for people to administer,
as they won't always have the specific language skills we might like them to
have.
A big mailing list would take as one parameter the location of a list of
members, not the list itself, that location realistically needs to be
written down in a text file, unless you want to produce tools to manipulate
something like the windows registry. On the other hand a number of products
which have crossed from windows to Linux have solved the lack-of-registry
problem by writing their keys out to a text file.
I also think we should look to the example of httpd, which has a quite
bewildering variety of parameters that can be configured, but people are OK
with that because they *don't* need to configure it with C++ or shell
scripts, nor do you have to re-compile anything when you change the
configuration, just hack at the conf files and kill -HUP. There are mods too
which can store information in databases mod_auth_mysql is one, but this
still has to be configured in a text file.
XML is an off the shelf format for this kind of information
>
>
> In gem, if there is an error, you throw an exception.
> And you can catch exceptions if it suits your purposes.
>
> I can't figure out how you could do this in James... Given
> general purpose Mailet's X and Y, you want to do X
> and if that fails do Y. In gem you write a Gemlet "Z"...
general purpose mailet X, if it fails it would set the message state itself
such that a matcher would "pull" the message into Y, it could set one of
several states depending upon the outcome. there would be no Z.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
