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. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
