On Feb 4, 2008 9:55 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > > i think that we should separate the mailet code from the server > > codebase in trunk. i can see two easy initial products: > > > > i'm tempted to move quickly to a VOTE since there seems to be a rough > > consensus but i'll post this first just in case anyone wants to jump > > in with objections, ask for clarifications or come up with improved > > names. so now's your chance ;-) > > > > - robert > > > > name: standard-mailets > > contents: mailets and mailet utilities decoupled from JAMES server > > (see stefano's analysis) > > rationale: mailets should be reusable outside JAMES. separating them > > from JAMES server is an architectural improvement and means users can > > take mailets without having to take the rest of JAMES > > > > name: security-mailets > > contents: SMIME, PGP/MIME, security utilities > > rationale: security is a specialist area with specific dependencies. > > easier to version and release independently. > > IMHO a single product, with a single downloadable package, would be > better as a first step.
seperating the security mailets out makes a lot of sense: 1. they use cryptography and this means obtaining permission to export 2. they may need regularly update releases to track fixes of security issues in the libraries they use > Furthermore our website layout does not easily accomodate many products. > > Maybe a multimodule product, including the "mailet-utils" generic > library and various modules depending on dependencies (standard-mailets, > security-mailets, sieve-mailets, and so on..) would be better? in terms of generating the website, i agree that a combined site makes sense for all mailets in terms of coordinating releases, insisting that to release security mailets a new release is needed for all mailet libraries seems unnecessary creation of work - robert
