Re: JAMES SMTP API sub-project proposal

[Aaron Knauf]

Ah ha! It seems that the world has not stopped while I've had my head down over the past few days!

As far as extracting the SMTP API so as to re-use it goes - I might just let that one drop. As has been mentioned a number of times, it doesn't look like there is much enthusiasm for that idea. C'est la vie!

Here are a few other ideas/viewpoints along similar lines as those previously expressed on this thread. Some of these ideas are already provided in the current JAMES version. I list them here because I want to express the features that I feel are important.

I would like to see several things come out of the v3 Mailet API -

* Standardised access to mail repositories. Whatever form that may take, I would like to be able to read and write (and even query?) the mail repository. I would also like to be able to define arbitrary repositories - although doing this in via config files is probably more useful than doing it in code. I would also like to be able to define named repositories and reference them by name from my code.

* Mailets should be (able to be) first class Avalon citizens, with access to the same services, lifecycle support and deployment semantics as any other avalon component. This should be done without requiring that they be made into standalone components. (The current "put your mailet on the classpath and reference it in the config file" method should still work.) This could be supported by exposing the JAMES config as a (dare I say it?) API that other components can use to register themselves as mailets. (This is realy just an idea for discussion - I'm not even sure it has merit, myself!)

* An embeddable way of handling incoming mail is desirable. I still don't think an embeddable mailet container is necessarily the best approach. Something that lets me accept a SMTP connection and spits out a Mail object for me to do as I please with is all that I require. This means, essentially, a mailet. However, a Mailet no more necessitates the present whole mailet container shebang than does a JMS MessageListener! I believe that the Mailet container could easily be a Mailet! (Composite pattern.) Ooops - there I go again. Never mind I am wearing my asbestos suit. :-)

I don't like the idea of reproducing (even some of) the Avalon Framework features in a Mailet-specific clone. This smacks of re-inventing the wheel. What is it about the Avalon Framework that makes it unsuitable for adaptation to this use? (Or even use without adaptation?)


Cheers

ADK


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>