> I want to expose javax.sql.DataSource's via JNDI so matchers/mailets ...
Do we really want to require JNDI in the Mailet API? If you say yes, I
won't grouse, but it will open the door to a lot of stuff. If you say no,
then we'll need an alternative way to pass the DataSource (which I agree
with you about, btw).
> > - Full Function Mailing Lists
> Related to this, I am thinking through a VERP gateway...
<<grin>> Would you believe that early in my discussions with Brian,
predating the posting of his requirements to infrastructure@, one of his
comments was "We would *really* need ezmlm-equivalent functionality, with
VERP bounce handling and all that." :-)
Having a JDBC database as a known part of the environment is getting better
and better.
> > - Dynamic Reconfiguration
> This isn't very easy
As a first cut, I want to be able to reconfigure the pipeline, list of
server names, and some other items without having to restart James. I am
lessor on the dynamic recompile for two reasons: (1) if we have the ability
to dynamically load matchers/mailets from outside the sar, then if the
classloader is associated with a pipeline, some of the reloading issues go
away; (2) if more matchers/mailets are written using the BSF support, then
there is no class loading issue at all.
> - Remove Finalizers
> Which finalizers?
I think we are actually fairly clean, but I want to make sure.
> > - Security
> What do you mean by security?
My notes say "base code, mailet loaders, sockets, file directories, etc.",
so I believe that my intent was that James not require a wide open security
policy, but would be able run with the Java 2 security manager enabled.
Related to that, the Mailet security line item was to suggest that Mailets
not have free run to do whatever they want. This seems important to me as
we open the door to third party classes.
> > - GeoMatcher
> Cool, just reminder that the geo-ip guy gave us rights to bundle the
> free copy of their IP lookup table with James.
I know. That's what I used. It is just time for me to polish it up for
others to use. An issue has been the lack of a matcher parameter to tell it
where the database is located. I hardcoded it for myself, but linux is not
MS-Windows. :-)
If we are to have this for v2, I'll probably have to do something like:
match="GeoMatch=[URL]:<country-list>"
unless someone comes up with a better idea.
> ** DRAC support
Added to Wiki page.
> ** Mail attributes
<<smacking forehead>> Not sure how I left Mail and User attributes off my
list, since I've talked of them often enough. Yes to arbitrary objects
associated with Mail and User objects by key value.
> ** Message repository directory structure
Hmmm ... I agree with the premise of why, but I'm not sure about the how.
Seems overly complex, but maybe I'm reading something into it that isn't
there.
If we're going to have User attributes, then why not associate a repository
directly with the user? This would provide flexibility, and given the
presence of a tool for copying between repositories, seems to provide a nice
admin capability. And an admin can switch repository types without
accidentally screwing up existing users, OR migrate users to another
repository type.
What do you think of handling mail repositories that way?
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
