james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: JAMES technology uplift
Date Wed, 02 May 2007 10:36:38 GMT
Noel J. Bergman ha scritto:
> [..]
> Conceptually, JAMES is made up of the following pieces:
>   - Wire level protocol handlers, which break down into:
>     - Incoming Message Acceptors (e.g., SMTP)
>     - Incoming Message Providers (e.g., POP3)
>     - Outgoing Message Delivery (e.g., RemoteDelivery)

We have all of them (you forgot fetchmail)
- Outgoing messages via PUSH model (remotedelivery)
- Outgoing messages via POP model (pop3server/imapserver)
- Incoming messages via PUSH model (smtpserver)
- Incoming messages via POP model (fetchmail)

> [...]
> The parts can be implemented as POJOs, but they need to know how to
> communicate.  We need to balance flexibility with implementation of random
> ad hoc interfaces.  For example, if we adopt JCR, we should document how we
> are using it, and provide some convenience wrappers for common things that
> we do, but we should not try to create another abstraction for storage.  The
> JCR *would be* the abstraction.  Period.  In other areas, POJOfication
> allows a lot of flexibility, but we still have to build a working server.

About JCR being the abstraction "period", I would say.. "maybe comma"
;-) Let's see it working before placing periods.

> Danny raised an interesting idea, which would be to host the mailet pipeline
> in an EJB container, e.g., OpenEJB.  My revised spooler notes from way back
> when also made some mention of the possibility of using an MDB, but I hadn't
> really given much thought to actually running JAMES in an EJB container.
> However, although there may be some initial resistance, it does make some
> sense.  For one thing, it provides a standard platform for JAMES, and opens
> up lots of options for deployment.  So how might this work?
> Once the SMTP server has put the message into JCR, a JMS message can be sent
> to a destination attached to an MDB, which in turn invokes the spool manager
> to start processing the message.  By providing two standalone methods:
> message storage (JCR) and messge processing initiation (JMS), any Java code
> could provide messages for a pipeline.  A pipeline, not *the* pipeline,
> because the JMS destination would be a configurable means to determine where
> the message starts processing.

So you revamped JMS, too ;-)

I'm fine with JCR and JMS (if they satisfy our requisites). I prefer to
not require a full J2EE stack for running it. If we build upon JCR and
JMS we already provide lots of options for deployment. Btw it seems you
switch deployment options too fast ;-) .. yesterday (some months ago)
everyone was for OSGi... I don't read OSGi in this mail...

Hint: maybe the message driven pojo approach (see
http://jencks.org/Message+Driven+POJOs) is more lightweight than MDB.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message