[Reply in multiple pieces based on sub-topic]
> A few months ago, I had a very interesting conversation with Pier on
JAMES.
Thanks for the background. I'd heard some of it from Serge over time. And
the servlet topic gets brought up from time to time by people who see the
obvious similarities, but not the key difference.
> Pier had pretty rock solid arguments *not* to use JAMES as a MTA
> and all came from the sysadm paranoia
One example would be that you run James as root in order to access the
privileged ports. And if James runs as root for the ports, all of the code
runs as root. There are OS specific workarounds, but it is a valid view.
> Unfortunately, I don't recall exactly what his arguments were, Pier, do
> you have a minute to chime in? I think the JAMES people would love to
> hear your criticism.
Absolutely! :-) Although the discussion would probably be more appropriate
on the James Developer mailing list than here.
> [qmail's] separation-of-concerns-driven design is incredibly solid
> and very scalable, something that can be matched (or even improved,
> I believe) in a multi-threaded environment, but this gives a single
> point of failure to the system that is not acceptable from a paranoid
> sysadm point of view.
James already has a pipeline architecture. The issue you are raising is
that the pipeline is in a single process. One of the things we've talked
about is allowing multiple distributed processes coupled through stores.
There is a plan; it just takes time and resources to get there.
Actually ... hmmm ... now that you've got me thinking about it, it occurs to
me that it should be possible even now to separate James into separate JVMs
for the SMTP service, mailet pipeline, and POP3 service. Once the SMTP
service puts a message in the pipeline, its done with it, so that's OK.
Once the mailet pipeline puts a message in the pop3 store, its done with it,
so that's OK. This approach would not have a multi-process mailet pipeline
(which requires the new spooler), but it would allow the majority of the
code to run in normal user mode, and would allow different parts to be
restarted if/when desired.
You know ... I think that would work just fine. Maybe a bit of a tweak in
some spooler code.
> Java doesn't have concepts like native process forking capabilities
Java has threads, instead. Not all operating systems support fork(). You
can launch new processes, but they don't start as quickly as a fork. It
would be nice if JVM startup were light(er)weight in the presence of an
already running a JVM.
> no notion of OS security
The Java 2 security model and JAAS are different, but effective. In terms
of file system items, it seems to me that a JNDI service provider could
provide full OS functionality by mapping file system specific properties to
JNDI attributes.
> As you, I would love to see JAMES be used as the ASF email
> infrastructure because it would allow fancy interoperability,
> expecially between the email realm and the web realm, which are,
> historically, hard to mix in an elegant and coherent way.
> At the same time, I strongly believe that without a healthy amount of
> native code, it is impossible to match the sysadm needs and fears.
As I've said, one of the reasons for picking the ASF mail server as a goal
is that provides a concrete set of important, real-world, requirements that
should be met.
So when you say:
> I'm aware that Noel wants the apache mail infrastructure to run on james,
> which is a goal I would *love* to see happening, but I fear that he's not
> taking into account the sysadm paranoia that runs in the apache
> infrastructure team.
please understand that simply being the ASF mail server is only the
destination. The value comes from what will have had to happen to get
there. In other words, being the ASF mail server isn't the point. Being
good enough to be the ASF mail server is the point.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
