Thanks for so many quick replies. I will take a look at JSieve though
since I know Rhino I must confess that sounds quite attractive.
>From your comments I gathered a next generation API might on the cards
and also that a change to support multiple matchers (other than a
JSieve / Rhino option) might get quite extensive. So I should probably
say I have been considering writing a semi-clean-room mailet
container. I had in mind these requirements:
1. support all existing matchers and mailets unchanged (if possible)
2. use Spring for dependency injection but limit Spring coupling to the loader
class
3. Mail will be injected into the mailet container via a JMS Listener
and should run in:
a) stand-alone apps
b) Message-driven ejb
c) web-application embedding
4. depend on nothing from James except mailet sdk (ok maybe this is
too far, but anyway I want to eliminate the avalon dependencies)
do you have any comments / advice on if this is a good idea or would
be of any interest within James 3 (or whatever it will be known as)?
if i do go ahead it will only be the mailet container not the
fetchmail, smtp (or other) services which i'd like to be pluggable.
tim
On 21/11/2007, Steve Brewin <[EMAIL PROTECTED]> wrote:
> Noel J. Bergman wrote:
> >
> > > i didn't see this before but blending jsieve with mailets would be
> > > quite powerful
> >
> > No time to respond properly, but yes, I've said so multiple
> > times. :-)
> > Steve's primary use case is within IMAP, especially for your:
> >
> > > one use case would be for safe per-user scripting
> >
> > but I like the idea of using Sieve in the mailet pipeline, too.
>
> Me too! I don't have time to search the lists but as I recall there was
> active discussion about this between Noel, Danny and myself at the time the
> initial jSieve implementation was done.
>
> As I recall (and it is awhile back, so my memory is hazy), with a little
> work JSieve could be plugged in to the same layer as the mailet pipeline,
> rather than as now, being a second class citizen dependant on the
> constrained mailet api. This way, JSieve could be configured as a processor
> in the pipeline where appropriate. It could be configured in many ways,
> ranging from do everything through to handling local delivery. The default
> processor technology would continue to be mailets, but Sieve (and others)
> would be configurable alternative processors.
>
> I'm afraid I just ran out of time to work on this.
>
> If anyone does have the time to move this forward I will try and refresh my
> memory a little more.
>
> Cheers
>
> -- Steve
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Tim Stephenson
e: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
