Danny Angus wrote:
I get that but still think that implementing escapes to other languages
might look better via a mailet.
I find these languages mainly useful because (in addition to being
easier to edit than XML IMO), it provides flow control that our
LinearProcessor does not, e.g., local varia
> > I believe that adding Jelly support to the current Mailet
> > container is a better route than creating a new container.
>
> Why? The current container knows, or will know when some
> code is moved out
> of JamesSpoolManager, how to initialize its matchers and
> mailets from its
> own XML con
> A language like Sieve, which is now an RFC, has its own notion of
matching,
> flow, and operation. As Steve pointed out, we could wrap all of that in
a
> Mailet (using the All matcher), but that seems kind of odd.
I get that but still think that implementing escapes to other languages
might
> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]
> Sent: 18 November 2003 04:15
> To: James Developers List
> Cc: [EMAIL PROTECTED]
> Subject: Re: Future direction for James
>
>
> Jason Webb wrote:
> >>Personal filtering sh
>By the way, I would consider starting this by forking LinearProcessor,
Oh what a good idea!
Yes +1 good stuff.
***
The information in this e-mail is confidential and for use by the addressee(s) only.
If you are not
> I don't see the advantage of creating a new container just to get the
> language support for matchers, which seems to be part of what you are
> suggesting, if I understand you correctly.
I was trying to accomodate Noel's idea, I'm not 100% sure why he thinks we
need a SIEVE processor, but I
Noel J. Bergman wrote:
Sieve would be nice if there is the impression that other people are
familiar with it. That said, I'm not sure there really is.
A year ago, sieve wasn't an IETF RFC, and there were maybe two sieve related
projects on SourceForge, one of which was CMU libsieve. Things have
c
> Sieve would be nice if there is the impression that other people are
> familiar with it. That said, I'm not sure there really is.
A year ago, sieve wasn't an IETF RFC, and there were maybe two sieve related
projects on SourceForge, one of which was CMU libsieve. Things have
changed, although I
Noel J. Bergman wrote:
Still, what is the real value that a Sieve container brings? Sieve suport
would make James configuration more administrator friendly, a major area
concern for many.
As-is support of an IETF standard for common mail behavior where the full
power of James' custom matcher/mailet
Noel J. Bergman wrote:
I'm not adversely disposed to relaxing this but I'd like to know
why we'd choose a processor over a mailet for the role.
A language like Sieve, which is now an RFC, has its own notion of matching,
flow, and operation. As Steve pointed out, we could wrap all of that in a
Mail
> I believe that adding Jelly support to the current Mailet
> container is a better route than creating a new container.
Why? The current container knows, or will know when some code is moved out
of JamesSpoolManager, how to initialize its matchers and mailets from its
own XML configuration eleme
Jason Webb wrote:
Personal filtering should be personally configurable. How
might that be achieved? Using Sieve scripts associated with
each users mailbox.
Yes. When I finally get round to completing the work on user attributes
;)
You don't need user attributes for personal filtering. If/once we
> Mailet was the atomic unit of processing and that any escape from
> the Mailet API into any other system used to process the messages
> should be done using a Mailet as a gateway.
> I'm not adversely disposed to relaxing this but I'd like to know
> why we'd choose a processor over a mailet for t
Jason, Steve and Danny (who remembered),
> Spam is always personal.
> Therefore I think that users should have a processing pipeline as well.
> When LocalDelivery runs it should not just blindly deliver the mail, it
> should execute the user's mail pipeline as well.
See: http://nagoya.apache.org/
> > - No consensus on how to support more complex processing logic (matcher
> > params, BSD scripting, etc...)
> Let's start implementing
http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3/MailetConfiguration #1
in v2.2.
You want to do that now? Before we make the next major release?
By the w
OK. Then next step.
Architecturally, this is a sound piece of refactoring. In my view, it is
only worth doing if we are going to have another container to support, and
further, that the new container adds real value.
To add real value the new container has to offer something that the current
Mail
Danny Angus wrote:
> Lots!
Danny,
I agree that where we are simply introducing support for expressing
conditional logic and evaluation in a scripted language, that this is best
done within the current Mailet container, so as to continue leveraging the
existing declarative mail flow.
I don't see
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]
> Sent: 17 November 2003 15:11
> To: James Developers List
> Subject: RE: Future direction for James
>
>
>
>
>
>
> > Therefore I think that users should have a processing pi
> Therefore I think that users should have a processing pipeline as well.
> When LocalDelivery runs it should not just blindly deliver the mail, it
> should execute the user's mail pipeline as well.
W/O trawling through this discussion I think you've just resurected an idea
from days of yore.
> -Original Message-
> From: Steve Brewin [mailto:[EMAIL PROTECTED]
> Sent: 17 November 2003 14:28
> To: 'James Developers List'
> Subject: RE: Future direction for James
>
>
> Jason Webb wrote:
> > When LocalDelivery runs it should not just bli
Jason Webb wrote:
> When LocalDelivery runs it should not just blindly deliver
> the mail, it
> should execute the user's mail pipeline as well.
Its perfectly legitimate for a company to have a system wide policy of what
it denotes as Spam and reject such mail in the mail server.
Its also conciev
Whilst we are on the subject of the processors and processing mail...
This is a bit of a rant, but I do eventually get to the point.
I notice that quite a few people have used the idea of a spam catching
matcher/mailet combination.
This made me think about where and when to catch spam.
All the exa
Hi,
Please read to the end before you reply, it may be dull but I believe it's
important..
> Ah! You mean that creates an instance of class
LinearProcessor,
> which currently is hardcoded to launch the Mailet container. We can add
> flexiblity, making it possible to launch other containers,
> Noel, does the above summarise "the major thought in [your] head"?
Very much so.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Noel J. Bergman wrote:
> I think that the major thought in my head was that the
> processor would have
> more full access to James, as opposed to the portable Mailet
> container.
Ah! You mean that creates an instance of class LinearProcessor,
which currently is hardcoded to launch the Mailet cont
> From: Serge Knystautas
>
> James was originally created for the mailet concept, i.e., Java based
> email processing. This has been done "ok" so far.. the 2.2 release has
> a better classloader that makes it easier to do this, but there still
> hasn't emerged a great Mailet SDK/IDE plug-in.
> Having looked at sieve, a mail filtering/manipulation
> language, what I see is something equivalent in our
> current syntax to
>
>
> sieve code
>
>
I think that the major thought in my head was that the processor would have
more full access to James, as opposed to the porta
Noel J. Bergman wrote:
> We can still
> have your ScriptedMatcher and ScriptedMailet, too, but there
> are some cases
> (sieve comes to mind) where the semantic matches up better as
> a processor
> than a matcher/mailet model.
I still don't get it. Having looked at sieve, a mail filtering/manipul
> > I am thinking that we could have a JellyProcessor, e.g.,
> > > class="org.apache.james.transport.JellyProcessor">
> > ...
> >
> > allowing the script to handle its own matching and
> > functionality.
> I'm not sure that we need to force Jelly, or any other scripting
Noel J. Bergman wrote:
> I am thinking that we could have a JellyProcessor, e.g.,
>
> class="org.apache.james.transport.JellyProcessor">
> ...
>
>
> allowing the script to handle its own matching and
> functionality.
I'm not sure that we need to force Jelly, or any othe
Soeren Hilmer wrote:
Well I believe that Merlin is a must (IMO Phoenix is dying), but apart
from
that JBoss etc. is not that interesting. Geronimo might be interesting
when
it sees the light (is Geronimo Merlin based?)
Geronimo is not Merlin based.
Geronimo is a J2EE container whereas Merli
On Wednesday 12 November 2003 21:54, Serge Knystautas wrote:
> James was originally created for the mailet concept, i.e., Java based
> email processing. This has been done "ok" so far.. the 2.2 release has
> a better classloader that makes it easier to do this, but there still
> hasn't emerged a g
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 spoo
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
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.
> Yes, the matcher/mailet syntax issue does need to resolved.
I think
I am not bothered about running James inside JBoss, Tomcat etc.
Whether the config is XML or whatever doesn't bother me.
Getting rid of the restart after a config.xml change would be useful.
Friendly sysadmin would be useful to me for "selling" James to clients.
As Noel said, make it a better mail
> IMHO, one area that James struggles is configurability:
> - Restart for every conf change.
Has been and would be nr. 2
> - All in XML files (or worse, a database)
id say as most comments before thats ok, a GUI would certainly lower the
entrance level of new users so nr. 3
> - Troubleshooting
> - Restart for every conf change.
I took a long hard look at dynamic reconfiguration a while back and came to
the conclusion that it was primarily the Avalon container that would have to
support this, but Phoenix did not. In addition, the Mailet API would need to
be extended to provide parallel s
> - Restart for every conf change.
The container can help with this, as can a refactoring of the process.
- All in XML files (or worse, a database)
<> This bothers me not at all.
> No consensus on how to support more complex processing logic
> (matcher params, BSD scripting, etc...)
I think we
I would vote for b)
Much better admin, and make it extensible like like the mailet and matcher
Like you said, be able to load mailets and matchers dynamically.
Continue down the scalability/robustness path
that would be the order of my preferences. I don't care what container
it runs in.
Cheers,
S
40 matches
Mail list logo
