Guys, Bill and Alex notwithstanding if we want to implement javamail storage, should we not be doing this *either* by implementing it compliant with Mailet, *or* first refactoring Mailet to take account of requirements of storage implemented with javamail.
In the former case the javamail implementation would, by definition, work with the existing mailets, and in the latter existing mailets and storage implementations would have to honour the new contract. Thus the javamail implementation would, in both cases, be interchanegable with exsiting implementations. Or is the proposal to replace mailet interfaces with javamail ones? If so -1 because.. I happen to like the ideas expressed here earlier by myself and others, that we might pursue a number of alternative file formats for mail storage in order to improve interoperability and migration between James and popular existing software. This is not limited to MTA's. I expect that there is a lot of mail processing software, virus and spam scanners for E.G. which scan files in one or other of the common formats, and possibly even listservers which could be allowed to run in conjunction with James if James used one of these formats. If this proposal is to replace the exisiting repository implementations and re-write the repository contracts in order to offload this responsibility to javamail then, like I say, -1. d. > In any event, my point about migration is simple. We won't preserve two > implementations of the mail repository for the interim. But > during initial > development, we don't have to change the spool implementation, > and we really > don't need to change the ToRepository mailet, which is used to > dump spam and > error in the stock configuration. At the beginning, the only > things that we > HAVE to change are the LocalDelivery and POP3 handler components. > > 1. Change LocalDelivery and POP3 to use JavaMail stores. > Use one of the existing JavaMail stores. > 2. Test, tweak, test again. > 3. Change ToRepository Mailet > 4. After the spooler is replaced, we can remove the current > mail repository interface. As I understand it, we also > convert our implementations to JavaMail stores. > > This incremental development is intended to make sure that we > have a working > server throughout the entire process. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
