On Jan 24, 2008 11:17 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Danny Angus ha scritto: > > On Jan 23, 2008 12:13 AM, Steve Brewin <[EMAIL PROTECTED]> wrote: > >> Would it be possible to further classify Stefano's excellent list of new > >> functionality in trunk to indicate which rely on none, minor or major API > >> and schema changes? Then we could evaluate what is the 'low hanging fruit' > >> that we could most easily harvest for an initial milestone drop. > > > > > > Sounds like a good idea, I'll give it a go. > > > > d. > > Sorry but most of that features has been written 13-24 months ago and my > memory is very limited. I don't know if Norman has better memory of the > specific changes. > > For what I remember the FIRST task has been to refactor services > interfaces to accomodate new features and then we started adding new > features. Most of the features we didn't include in 2.3 was delayed > because they required critical API changes, so I guess most of the > features we kept in trunk for so long are there because they required > API changes. > > I'm not sure about "schema changes": if you mean the db schema, then > IIRC there are no changes required on the db. Excluding the *new* IMAP > code and its backend libraries (mailbox manager) the rest of the code > SHOULD be storage and config.xml backward compatible with the v2.3 branch. > > I won't go in the svn logs to understand what changes each feature > required, I have not enough time for a similar task. If anyone is > willing to do this then I can tell that I tried to use JIRA-XXX labels > in most commits (not every, sorry) and to have a JIRA issue for each > feature I worked on, so starting from JIRAs and their "Subversion > Commits" pages could help. > > 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 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. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
