Danny Angus wrote:
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.Yes, mail repositories (or stores, or whatever... a place to put/retrieve mail) would be great.
+1 this is on the agenda
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!)
I'm opposed to the idea of exposing Avalon, or James internals to Mailets. I'm in favour of making the Mailet API as self-referential as is possible (within the bounds of reason) and even allowing mailets to be aware of James avalon based internals would break this.
Yes, self-referential and lean.
Yeah, maybe someone could contribute JavaServerMail (the complement to JavaMail) as a subproject if there are willing contributors and James becomes a top-level project.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!No but then again if we do produce a stand-alone/embeddable/james-independant mailet container you get the rest for free. Additionally I still feel that producing stand alone components is beyond the scope of the project.
Yes it does, and I forget as well. :) I think it would likely have to do with (1) configurability and (2) processing control (so the mail server can split the complete processing into multiple phases, and so allow it to periodically pause-save-resume later the processing).I believe that the Mailet container could easily be a Mailet!This is very true, I looked at making the spoolmanager, and processors all honour the mailet contract, Serge had reservations, which I forget.
Yes to backwards compability, yes to lean, yes to no Avalon dependencies. Anyway, looking forward to the discussion.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?)
I have no objection to the Avalon Fraework per-se but IMO if we are to encourage others to develop mailet containers I believe that it is in our interests to produce an API with a very small footprint and as few external dependancies as possible. The Mailet API is about to undergo a third revision, at which point we should have a funtional, stable and possibly final version. It would be difficult to ensure the stability of an API which depended on an external project, harder still when that project can't guarantee its own stability. If we were then to extend or alter the API I would expect us us maintain backwards compatibility, something which we could never guarentee if we expose Avalon framework, and can't recieve the same guarentee from Avalon.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
