Bernd Fondermann wrote:
> other important parts are
> - User DB
Subsumed by "data store", at least for the moment.
> - Server Management
JMX, and I agree that we as long as we're going to do this uplift, we should
make sure that we provide appropriate JMX support. And see also JSR-138.
> - Message Orchestration
If I understand your meaning, this is subsumed by "Mailet Container".
> > However, although there may be some initial resistance, [running
> > JAMES in an EJB container] does make some sense. For one thing,
> > it provides a standard platform for JAMES, and opens up lots of
> > options for deployment.
> From my experience EJB incl. MDB does _not_ open options for
> deplyoment, they _narrow_ them.
I meant that it could be deployed in "any" EJB server.
> You would need an EJB container, and add much more footprint by the
> way than by adding a JMS implementation.
Actually, we'd have to compare the footprint of Phoenix vs OpenEJB as a
standalone container.
> There are so many lightweight and more flexible component models.
And none of them standard. As I understood Danny and a couple of others,
the goal is to lower the barrier to acceptance by being able to package
JAMES such that it looks as if they are just installing yet another
application into their existing application server.
> +1 for the basic architectural approach.
> But. What is completely missing is the important glue in between. The
> APIs which describe how components interact and what each component
> does. And I am not satisfied how it is done ATM. The object model
> would need to be revisited nevertheless.
The glue between most of them would be the JCR. Depending upon how the
spooler is deployed, JMS or similar event driver can initiate pipeline
processing.
How much should be in the Mailet API, or just documented use of other
subsystems (e.g., JCR), is TBD.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
