Robert Burrell Donkin ha scritto:
On Jan 24, 2008 11:17 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Many new service interfaces have been introduced to increase the
granularity of the components. Many interfaces have been simplified or
changed to better define services responsibilities/contracts. Many
"hardcoded" behaviors have been extracted to components and coupled via
service interfaces.
though i agree that this is good, it has exposed some issues. it's no
longer clear which APIs are:
* interior (to allow plugins for a particular implementation)
* exterior (intended for use for mailet authors and by consumers of
the function)
* management (optional instrumentation APIs)
this is one of the reasons why JAMES is hard to learn and why
components are hard to use outside
"it's no longer" ??? well, I accept this only because you wasn't here X
years ago. It has never been clear. The refactoring was a first step to
try to have a cleaner separation of concerns. The way to have a clear
separation in interior/exterior/management api is a LONG LONG way, and I
think that if this is a goal for the next release, then I guess there
will be no next release :-(
I suggest a step by step approach, but if there are enough skilled
volounteer to do the whole thing at a time, then this is COOL! I would
be excited.
there is a related problem with the current module system. for
example, the new IMAP implementation has an internal component
structure. this increases the number of modules and makes it hard to
understand the relationships between them.
?? are you saying that components make it more hard to understand
architectures? I don't get this.
IMHO there is no reason to have a single module for each component.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
