> +1 in general. just minor comments below. > > On 8/19/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > 2) Deprecate/Remove unused methods from common interfaces: e.g. > > MailServer provides 4 sendMails methods but only 1 is used from > > SMTPHandler and MessageProcessor. The other 3 methods are always > > accessed via the MailetContext interface (provided by the > same component: James). > > How do you deprecate/remove the unused methods when they are > used by the mailetcontext API? Sounds like you understand > the dependencies... > I'm just a bit confused about how the change.
I just want to remove the methods from the MailServer interface. The same method implementations are shared with MailContext and needed by MailContext users so the James class implementations will stay there. This makes more clear the resposibilities (it is weird that you can send mails via MailServer interface and via MailetContext in the same way. After the change MailServer will be used mostly for pop3/remotemanager operations) > > 3) Remove the inboundSpool concept from the MailStore by > promoting the > > "inbound" SpoolRepository to a toplevel block that James and > > JamesSpoolManager will depend on. 2 advantages: possibility to > > implement multiple spoolmanagers with multiple spoolrepositories, > > limit the interdependencies of components (the Spoolmanager > does not > > need the full MailStore but only the inbound spoolrepository). > > Sounds good. Makes sense that there is one (core) inbound repository. > Only concerned about confusing or duplicated conf file stuff. I will not duplicate the config. Just move the <spoolrepository> configuration outside from the <mailstore>. > > 4) Promote MailetLoader and MatcherLoader to block components: this > > allow us to make them easily configurable and allow to limit the > > knowledge needed by the SpoolManager (the spoolmanager > itself does not > > need the MailetContext knowledge). To do that we need to change the > > Loaders to be Serviceable and to remove the MailetContext > parameter from the load calls. > > Hmm, this sounds rather pervasive change since I believe it > affects where you would configure the processor chains. I'd > like to understand how this would affect the conf file. I still have to investigate better but I think I will only need to move the <mailetpackages> and <matcherpackages> outside from the <spoolmanager>. > > I would like to know if any committer is against this kind > of changes. > > Again +1 in general. Just would like a bit more specifics > since I'm too lazy/busy to think through how some of these > changes affect other parts. If you agree I think I can give more specifics committing the changes: you can see what I changed and we can always revert if you don't like the changes. Those changes are easy enough to implement that it does not make too much sense to discuss them theoretically. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
