On Mon, Sep 1, 2008 at 2:56 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: >> >> SieveToMultiMailbox is the major remaining issue on the road to >> separating out an IMAP protocol library. it's a good example of some >> of the problems with the remaining mailets in JAMES. hopefully, >> thinking about solving them in this case may be applied more widely. >> >> ---- >> >> SieveToMultiMailbox is tightly coupled to a large IMAP specific API >> (mailboxmanager) but uses only a tiny portion of it. an alternative >> implementation of the mailboxmanager API would be faced with >> implementing at least 29 methods spread over 3 interfaces. the mailet >> only delivers a mail to a mailbox which should really require a single >> call to a single method. this pattern is repeated across JAMES. the >> API is shared by protocols, data stores and mailets resulting in >> unnecessary large and imprecise interfaces. mailets typically only use >> a small subset of the function required by protocols and stores. >> explicit SPIs specialised for mailets would be a better approach. >> these could be independently versioned allowing the APIs used >> internally by JAMES to be safely varied. >> >> an SPI interface for mailboxes as simple as (for example): >> >> public void put(String url, Mail mail); >> >> would suffice >> >> ---- >> >> SieveToMultiMailbox is tightly coupled to avalon. the IMAP dependency >> is loaded by a service lookup using avalon. JAMES server is the only >> mailet container that is likely to support avalon. more modern IoC >> containers (for example, spring) would unobtrusively inject the >> required dependency. replacing magic lookup with construction >> injection would mean adding something like: >> >> public SieveToMultiMailbox(MailboxSPI spi) >> >> this would mean refactoring the mailet/matcher loading code to allow >> replacement by an implementation that uses a modern container. (i've >> always been keen on being able to ship independent self-contained mail >> applications built from mailets which could just be dropped into a >> running server.) the complexity would come creating a mixed system. >> using some sort of avalon-aware service adapters would probably be >> necessary. >> >> MailboxSPI might be provided by adapting a mailbox manager service. >> >> ---- >> >> opinions? > > I prefer setter injection to constructor injection (expecially as we have an > init method in the mailet api).
i know a lot of people prefer setter injection but constructor injection has some advantages in this case: 1. it prevents uninitialised use of the mailet. this should give a clean failure when anyone tries to use it with an incompatible mailet loader. 2. no conventions need to be established or explained. as a temporary measure, it's easy to check and inject a limited number of SPIs through reflection. i would prefer to avoid major changes before moving IMAP out > I don't understand if you are proposing something to be added to the mailet > specification ATM AIUI the mailet specification is silent on assembly and service acquisition. one advantage of this strategy is that it's possible to alter these characteristics without altering the mailet specification. IMHO factoring out the mailet loading and the processor assembly from the spool management would be a major step forward > or simply you are proposing to change the way james specific > mailets are written so to not require avalon knowledge to the james specific > mailets. IMHO JAMES specific mailets are an anti-pattern. we need to work towards decoupling minimal SPIs for mailets from the large APIs used internally by JAMES. i prefer to think about mailet loaders and processor assemblers indepedently. avalon is not a good match for this problem. more modern IoC containers like pico or spring as *much* better. i strongly dislike the use of the magic avalon service attribute. IMHO if a mailet is coupled to avalon then it should implement the standard servicable interface. the container could then recognize this and configure the mailet appropriately. > Another doubt is about the use of "String url": can you give more details on > the allowed values for url and the way it works (a couple of examples would > suffice, I guess)? i've been thinking for a long while that there might be a lot to gain in flexibility by moving towards APIs using URIs but it's still hazy... > Last point, and the least important, I don't like the SPI postfix. > The same interface could be used by SMTPServer/Fetchmail to store messages > to the spool. In fact a spool repository could expose this interface > (ignoring the url) or we could expose it via the Store by looking up the > appropriate spool repository and storing the message to it. i have been thinking about that direction for example, POSTing to "mailto://[EMAIL PROTECTED]" is an elegant and concise way to express the idea of forwarding a mail. this can be used for delivery as well. for example "mailet://[EMAIL PROTECTED]". the advantage of using URLs is that it's easier to present interfaces which work ok for a wider variety of protocols. for example POSTing to "imap://[EMAIL PROTECTED]/INBOX" could be distringuished from "james://[EMAIL PROTECTED]/INBOX" and "mailbox://[EMAIL PROTECTED]/INBOX". might be possible to do some interesting stuff this way. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
