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
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
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
I want to add a few observations to what Danny has already said in
this thread. I mention two classes, Message and Transport, which I
think could be improved by being super-classed, by giving each of them
a simpler parent. But this is based upon my limited experience with
using JavaMail's API
One detailed reason I find MimeMessage less than ideal is that Message
contains the method saveChanges(), and Method.saveChanges() re-writes the
Message-ID header.
James wastes clock cycles saving and restoring Message-ID when message
contents change.
Surely it is more efficient for saveChanges() t
Richard O. Hammer wrote:
I want to add a few observations to what Danny has already said in this
thread. I mention two classes, Message and Transport, which I think
could be improved by being super-classed, by giving each of them a
simpler parent. But this is based upon my limited experience w
Craig,
I'd like to see this added to the VirtualUserTable code. Better still, I'd
like to see the code refactored into AbstractVirtualUserTable, having the
code for virtual user table behavior, and JDBCVirtualUserTable, having the
code for fetching the virtual user table map from the database. T
Bill Shannon wrote:
> > One detailed reason I find MimeMessage less than ideal is that Message
> > contains the method saveChanges(), and Method.saveChanges() re-writes
the
> > Message-ID header.
> > The alternative, the compromise position I'd like to propose is this:
> > > Message.saveChanges()
> > 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:
> 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
Could someone point me to the list of major changes in 3.0.
I'm thinking of upgrading and I want to get a feel for
what it's going to cost me.
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: Fri 11/14/2003 2:03 PM
To: James Developers List; [EMAIL PROTECTE
> Could someone point me to the list of major changes in 3.0.
James v3 is barely in development.
> I'm thinking of upgrading and I want to get a feel for
> what it's going to cost me.
Cost you? Upgrade from what version to what version?
--- Noel
---
> 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
Cost me in terms of effort from the latest released version.
I keep seeing people suggest that the 3 code line is better than the
current packaged version.
On Nov 14, 2003, at 9:47 PM, Noel J. Bergman wrote:
Could someone point me to the list of major changes in 3.0.
James v3 is barely in developm
> Cost me in terms of effort from the latest released version.
> I keep seeing people suggest that the 3 code line is better than the
> current packaged version.
The v2.2 line is better. I don't know if we will release it as v2.2 or v3,
but it is better. And fully compatible.
--- Noel
15 matches
Mail list logo
