> 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.
+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. > 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. > 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. > 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. (just my 2c) d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
