Aaron, > Hmmm. I don't mean to be argumentative, or to divert JAMES off on my own > private development direction, but I do not believe that my goals in any > way conflict with the current JAMES project goals.
I don't mind some argument, and personally I don't find your goals to be the problem. It's the approach I find problematic and ill-advised. > Basically, my goal is to receive and process mail in-process with my own > app, as simply as possible and with as little overhead as possible. JAMES > appears to provide all of the building blocks required to do this - they > just need to be extracted (which doesn't seem all that hard). This goal can be achieved with the current design quite simply. No additional APIs necessary or desirable. To wit, run your app as an Avalon component within Phoenix. This takes advantage of a pre-existing API that is both widely used and well tested - the Avalon Framework. Have your mailet access your app directly, and communicate with your custom API that's part of your app. Piece of cake. And it's something that, in one form or another, we've committed to support in the next rev of the mailet API. I'd strongly suggest that you read the Avalon/Phoenix docs to get a clear picture of how something like this would work. > I will comment on both Danny's and Noel's replies, here. Not sure why my reply doesn't merit a response, but I'll reply to this nonetheless. > <danny> > the goal of the James project to provide James as a complete solution, not > a set of components. > </danny> > > Yes, ok. The JAMES project, as a whole would still produce a complete > mail > server, assembled from a set of components, which would include those > provided by Avalon and those provided by JAMES sub-projects. Fine, although a sub-project would need to be justified first. The additional complexity of a sub-project would need to be justified by one or another meaningful goal that are currently unachievable or difficult to achieve with the current product. So far I haven't heard any. > <danny> > modify the handler for incoming SMTP such that it could be extended by > "verb classes" to support new SMTP verbs. > </danny> > > Unless I misunderstand you, this would allow for custom extensions to the > SMTP protocol. This is not the goal that I am aiming at. I want to avoid > having to have a separate process, with the implied inter-process > communication, for receiving mail. You are correct. Danny's suggestion really doesn't help for your stated goal - mail processing in-process - unless you want to hijack the entire SMTP dialog. But allowing that capability seems to be part of the API you suggest (see my earlier email) which I find extremely problematic. There are right and wrong ways to do such things, and I'm pretty sure publishing a public API where the consumer of the API is required to assure RFC compliance is the wrong way. > <noel> > I believe that the approach desired by James would be an embedded Mailet > Container > </noel> > > If I understand the distinction you are making, then this would involve > embedding a much more heavy-weight component than necessary for a lot of > cases. Correct me if I am wrong, but this would mean both an SMTP > listener > (for receiving the mail) and a mailet container for processing it would be > embedded. That would give you all of the mailet chaining stuff, etc. but > this is not necessary in many cases (although I do not deny that it would > be useful in many others). This is not a correct interpretation. The SMTP server component and the mailet container are distinct components. That's not an accident. The SMTP server component is responsible for SMTP communication. The SpoolManager is responsible for mail processing. > <noel> > I think that your original goal, to facilitate projects that > need to receive and process in-board e-mail, is something to support. I > just disagree with your initial proposal to solve that problem. > </noel> > > I am open to suggestions. I lean away from your embedded mailet container > in the form that I have described it above, due to it's being too > heavy-weight. Perhaps your tuple-spaces idea could be used to aid with > this? Have James receive the SMTP connections and write it to a > persistent > spool, and have other apps able to receive that mail and process it by > reading mail from the spool - a kind of publish/subscribe scenario? I > haven't thought about this one very hard, but it seems to dovetail nicely > with your massively scalable distributed JAMES idea from last week. I > still think that an embeddable SMTP interpreter would be useful in > addition > to this, however. See my comments above. Everything you want to do is already doable. No need for additional sub-projects, API, or what-not. The SMTP server publishes messages to a spool. The SpoolManager picks those messages off the spool (publish/subscribe, in process) and sends them to the first processor. Your custom mailet, which does whatever you want it to do, sits in situ and does whatever you want it to do (i.e. persist the message to your own spool, deliver it via an API to a custom app, etc.) > <danny> > a mailet containing spoolmanager entirely self referential apart from > standard Java & j2ee classes, this again would form the basis for an > embeddable mailet container and mailet development suite. > </danny> > > Again - this might fit with the tuple spaces thing. I think it is a good > thing. I don't thing it precludes the embeddable SMTP listener from being > a good thing, too. > > From the design objectives listed on the JAMES web site: > > <quote> > Protocol abstraction Unlike other mail engines, protocols are seen only > like "communication languages" ruling comunications between clients and > the > server. Apache James is not be tied to any particular protocol but follow > an abstracted server design (like JavaMail did on the client side) > </quote> > > This, to me, seems to imply that JAMES should be able to receive and send > mail via a number of transport protocols, which in turn implies protocol > abstraction and pluggability. In order to achieve this, a clear interface > must be defined for JAMES to interact with different protocol > implementations. Does this not mean that I ought to be able to utilise > the > same interface to interact with a protocol implementation from another > app? > It seems to me to be a small step from protocol abstraction to protocol > re-use - and in no way contra to the design goals of JAMES. No. The interpretation and drawn conclusion have nothing to do with one another. One of James' primary purposes is to abstract away the RFC protocols (SMTP, NNTP, IMAP, POP3) and allow administrators to do processing of the message independent of the protocol. It does this largely by providing correct, robust, effective implementations of the RFCs. Messages transmitted to James using these protocols are placed in a protocol-neutral (...abstraction barrier...) spool. The SpoolManager processes messages on this spool, and allows customization through the Mailet API. That's what makes it an abstract server design. > Certainly, I can see why you might not want to incur the administrative > overhead of a separate sub-project. To me, that is not important. It > would be enough to package protocol implementations as separate jars. > This > would also facilitate the development of alternate mail transports for > JAMES, perhaps allowing JAMES to receive mail from a JMS queue, instead of > an SMTP connection. No it wouldn't. It would break abstraction barriers that are already present and well respected by the code. There's actually already a server component that demonstrates the correct way to do something like this. That would be FetchPOP. It grabs mail from POP3 accounts and drops it on the spool, to be processed by the SpoolManager. Change POP3 to JMS, and you're basically done. No need for some SMTP listener API. It is not only possible, but easy, to maintain this functionality while completely deactivating James' SMTP server functions. > What I am proposing ought to make JAMES a more flexible a more widely > applicable product. Nope. It doesn't. Just makes it less robust, violates abstraction barriers that are well established, and introduces yet another API that we'd be tied to. > I am keen to hear the views of anyone that has an alternative approach to > suggest, here. See above. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
