james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Future direction for James
Date Thu, 13 Nov 2003 21:21:31 GMT
Steve Brewin wrote:
> Noel J. Bergman wrote:
> > I agree that dynamic reconfiguration is a container issue.  I
> > am not sure that we need to do anything with Mailets.  I think
> > that we can stick with the processor is a the configurable
> > entity, or possibly even just the spooler.

> The spoolmanager, and hence mailets, would be restarted to pickup any
> configuration changes

> Done this way the Mailet API does not change, but it places a much greater
> onus on mailets to free resources in the destroy() method as this cycle

Works for me.  I think that is a perfectly reasonable requirement.

> > > Yes, the matcher/mailet syntax issue does need to resolved.
> > I think we had a consensus on it, recorded in the wiki.

> Where is this consensus recorded? I only see
> http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3/MailetConfiguration
> which documents three proposals, but no outcome.

We can revisit it, but we had settled, IIRC, on proposal #1.  The use of
<parameter name=""> instead of <name> requires a change, but was considered
desireable because it would allow scheme validation.  Proposal #2 was
rejected, as Danny is strongly against such complicated XML representation.
Anything more complex than handled by proposal #1 was going to be exposed
via JNDI.


> >  That should allow the use of BSF.  Also, I think that
> > it makes sense to consider a Jelly processor...

> Once the new mailet syntax is in place Jelly should probably
> be included in an update of the scripting support.

I am thinking that we could have a JellyProcessor, e.g.,

   <processor name="custom-stuff"
              class="org.apache.james.transport.JellyProcessor">
     ...
   </processor>

allowing the script to handle its own matching and functionality.  When you
look at something like sieve, this also makes sense.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message