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 don't understand if you are proposing something to be added to the
mailet specification 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.
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)?
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
