Re: [PROPOSAL] New Mailet Products
Robert Burrell Donkin ha scritto: On Wed, Feb 6, 2008 at 5:40 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: Robert Burrell Donkin ha scritto: > On Feb 6, 2008 8:40 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >> Robert Burrell Donkin ha scritto: >>> On Feb 5, 2008 7:32 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: 2) Will the mailet util library be an "util" product similar to api, std and crypto? >>> not sure we need a util library ATM. if possible, i'd prefer to >>> include the utils in std for now. >> The only issue is that some "library" module in james-server will have >> to depend on std-mailets because of these utilities (unless we duplicate >> the utility code). >> But we can split them later, if needed. > > providing that it's the coupled classes are mailets that haven't been > moved from JAMES then i'm happy for a temporary dependency > > - robert Some example that does not satisfy the requirement: mailets/ClamAVScan - import org.apache.james.util.io.IOUtil; Maybe this could be translated to a commons-io dependency mailets/SpamAssassin - import org.apache.james.util.SpamAssassinInvoker; What to do with this? An smtphandler in in smtpserver in james may require the same code. That's why it has been astracted to an utility class. mailets/AbstractRedirect and the associated tree - import org.apache.james.util.mail.dsn.DSNStatus Maybe this should land mailet-api sooner or later. - import org.apache.james.util.mail.MimeMultipartReport Not sure what code uses this. - import org.apache.james.util.MimeMessageUtil(for writeMessageBodyTo) Maybe this function is simple enough we can duplicate it. WDYT? all sounds doable with a little thought and effort i think that the principle's right and we can move most of the mailets quickly and easily. there are probably some which are more difficult and maybe some where the effort involved is probably greater than the gain. unless anyone jumps in with more comments soon, i'll pull together something that people can vote on... -robert +1 Stefano
Re: [PROPOSAL] New Mailet Products
On Wed, Feb 6, 2008 at 5:40 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > Robert Burrell Donkin ha scritto: > > On Feb 6, 2008 8:40 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >> Robert Burrell Donkin ha scritto: > >>> On Feb 5, 2008 7:32 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > 2) Will the mailet util library be an "util" product similar to api, std > and crypto? > >>> not sure we need a util library ATM. if possible, i'd prefer to > >>> include the utils in std for now. > >> The only issue is that some "library" module in james-server will have > >> to depend on std-mailets because of these utilities (unless we duplicate > >> the utility code). > >> But we can split them later, if needed. > > > > providing that it's the coupled classes are mailets that haven't been > > moved from JAMES then i'm happy for a temporary dependency > > > > - robert > > Some example that does not satisfy the requirement: > > mailets/ClamAVScan > - import org.apache.james.util.io.IOUtil; >Maybe this could be translated to a commons-io dependency > > mailets/SpamAssassin > - import org.apache.james.util.SpamAssassinInvoker; >What to do with this? An smtphandler in in smtpserver in james may > require the same code. That's why it has been astracted to an utility class. > > mailets/AbstractRedirect and the associated tree > - import org.apache.james.util.mail.dsn.DSNStatus >Maybe this should land mailet-api sooner or later. > - import org.apache.james.util.mail.MimeMultipartReport >Not sure what code uses this. > - import org.apache.james.util.MimeMessageUtil(for writeMessageBodyTo) >Maybe this function is simple enough we can duplicate it. > > WDYT? all sounds doable with a little thought and effort i think that the principle's right and we can move most of the mailets quickly and easily. there are probably some which are more difficult and maybe some where the effort involved is probably greater than the gain. unless anyone jumps in with more comments soon, i'll pull together something that people can vote on... -robert
Re: [PROPOSAL] New Mailet Products
Robert Burrell Donkin ha scritto: On Feb 6, 2008 8:40 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: Robert Burrell Donkin ha scritto: On Feb 5, 2008 7:32 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: 2) Will the mailet util library be an "util" product similar to api, std and crypto? not sure we need a util library ATM. if possible, i'd prefer to include the utils in std for now. The only issue is that some "library" module in james-server will have to depend on std-mailets because of these utilities (unless we duplicate the utility code). But we can split them later, if needed. providing that it's the coupled classes are mailets that haven't been moved from JAMES then i'm happy for a temporary dependency - robert Some example that does not satisfy the requirement: mailets/ClamAVScan - import org.apache.james.util.io.IOUtil; Maybe this could be translated to a commons-io dependency mailets/SpamAssassin - import org.apache.james.util.SpamAssassinInvoker; What to do with this? An smtphandler in in smtpserver in james may require the same code. That's why it has been astracted to an utility class. mailets/AbstractRedirect and the associated tree - import org.apache.james.util.mail.dsn.DSNStatus Maybe this should land mailet-api sooner or later. - import org.apache.james.util.mail.MimeMultipartReport Not sure what code uses this. - import org.apache.james.util.MimeMessageUtil(for writeMessageBodyTo) Maybe this function is simple enough we can duplicate it. WDYT? Stefano
Re: [PROPOSAL] New Mailet Products
On Feb 6, 2008 8:40 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > On Feb 5, 2008 7:32 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >> 2) Will the mailet util library be an "util" product similar to api, std > >> and crypto? > > > > not sure we need a util library ATM. if possible, i'd prefer to > > include the utils in std for now. > > The only issue is that some "library" module in james-server will have > to depend on std-mailets because of these utilities (unless we duplicate > the utility code). > But we can split them later, if needed. providing that it's the coupled classes are mailets that haven't been moved from JAMES then i'm happy for a temporary dependency - robert
Re: [PROPOSAL] New Mailet Products
Robert Burrell Donkin ha scritto: On Feb 5, 2008 7:32 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: 2) Will the mailet util library be an "util" product similar to api, std and crypto? not sure we need a util library ATM. if possible, i'd prefer to include the utils in std for now. The only issue is that some "library" module in james-server will have to depend on std-mailets because of these utilities (unless we duplicate the utility code). But we can split them later, if needed. I'm not sure that maven will be happy with a similar structure, but if we can get maven to work (build the website) and the answers to the 2 questions above are "yes" then you convinced me and I'm fine with this solution :-) it works over in the commons Cool! Stefano
Re: [PROPOSAL] New Mailet Products
On Feb 5, 2008 7:32 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > we move the api down a level and group all mailet-related products. say: > > > > http://svn.apache.org/viewvc/james/mailet/api/trunk/ (<- > > http://svn.apache.org/viewvc/james/mailet/trunk/) > > http://svn.apache.org/viewvc/james/mailet/std/trunk/ > > http://svn.apache.org/viewvc/james/mailet/crypto/trunk/ > > > > the website is easy enough to sort out: like common, we svn:externals > > to create virtual modules. then we also have: > > > > http://svn.apache.org/viewvc/james/mailet/current/api > > http://svn.apache.org/viewvc/james/mailet/current/std > > http://svn.apache.org/viewvc/james/mailet/current/crypto > > > > the mailet website can be generated from this using the reactor > > > > - robert > > Ok, this way the project can be checkedout as a multimodule product but > our svn still contains the trunks/branches/tags for each module. yep > 1) We will need a pom.xml in > http://svn.apache.org/viewvc/james/mailet/current/pom.xml, right? yep > 2) Will the mailet util library be an "util" product similar to api, std > and crypto? not sure we need a util library ATM. if possible, i'd prefer to include the utils in std for now. > I'm not sure that maven will be happy with a similar structure, but if > we can get maven to work (build the website) and the answers to the 2 > questions above are "yes" then you convinced me and I'm fine with this > solution :-) it works over in the commons - robert
Re: [PROPOSAL] New Mailet Products
Robert Burrell Donkin ha scritto: On Feb 4, 2008 9:55 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: Robert Burrell Donkin ha scritto: 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 project organisation, IMHO mailets independent of JAMES belong with the API. so in terms of mailing lists and website organisation, i think it makes sense to group mailet implementations with the API. +1 we move the api down a level and group all mailet-related products. say: http://svn.apache.org/viewvc/james/mailet/api/trunk/ (<- http://svn.apache.org/viewvc/james/mailet/trunk/) http://svn.apache.org/viewvc/james/mailet/std/trunk/ http://svn.apache.org/viewvc/james/mailet/crypto/trunk/ the website is easy enough to sort out: like common, we svn:externals to create virtual modules. then we also have: http://svn.apache.org/viewvc/james/mailet/current/api http://svn.apache.org/viewvc/james/mailet/current/std http://svn.apache.org/viewvc/james/mailet/current/crypto the mailet website can be generated from this using the reactor - robert Ok, this way the project can be checkedout as a multimodule product but our svn still contains the trunks/branches/tags for each module. 1) We will need a pom.xml in http://svn.apache.org/viewvc/james/mailet/current/pom.xml, right? 2) Will the mailet util library be an "util" product similar to api, std and crypto? I'm not sure that maven will be happy with a similar structure, but if we can get maven to work (build the website) and the answers to the 2 questions above are "yes" then you convinced me and I'm fine with this solution :-) Stefano
Re: [PROPOSAL] New Mailet Products
On Feb 4, 2008 9:55 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > 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 project organisation, IMHO mailets independent of JAMES belong with the API. so in terms of mailing lists and website organisation, i think it makes sense to group mailet implementations with the API. we move the api down a level and group all mailet-related products. say: http://svn.apache.org/viewvc/james/mailet/api/trunk/ (<- http://svn.apache.org/viewvc/james/mailet/trunk/) http://svn.apache.org/viewvc/james/mailet/std/trunk/ http://svn.apache.org/viewvc/james/mailet/crypto/trunk/ the website is easy enough to sort out: like common, we svn:externals to create virtual modules. then we also have: http://svn.apache.org/viewvc/james/mailet/current/api http://svn.apache.org/viewvc/james/mailet/current/std http://svn.apache.org/viewvc/james/mailet/current/crypto the mailet website can be generated from this using the reactor - robert
Re: [PROPOSAL] New Mailet Products
On Feb 4, 2008 1:52 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Danny Angus ha scritto: > > > On Feb 4, 2008 9:58 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > > >> Are you referring to the repositories api and the mailet v3 sandbox? > > > > Indirectly. I'm *not* proposing making big API changes, but moving > > James interfaces to mailet would let us do 99% of moving mailets out. > > > >> I'm not sure Robert proposal is related to it Robert? > > > > I don;t see how we can move out mailets without doing that. > > > > d. > > In server-dev yesterday I wrote a big message about mailets with no > dependencies on james server and mailets with minor utility dependencies > (for which we could move the utility too) and mailets that requires a > small refactoring to be able to move them out. yes - these are ones i want to target plus the independent mailet utility code they rely on > It is a first step, and we will remain only james server specific > mailets in james-server, so it will be easier to understand what > interfaces we should place in the mailet api to move some or all of them > to the standard mailet product. +1 > We are not happy with repository interfaces in james-server now (at > least this is my understanding), so I'm not sure that moving them to a > public api (mailet api) will be a good thing. Furthermore any change > like this should be discussed in the mailet-api list as we are not the > only implementors of the mailet-apis. +1 - robert
Re: [PROPOSAL] New Mailet Products
On Feb 4, 2008 1:52 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > We are not happy with repository interfaces in james-server now (at > least this is my understanding), so I'm not sure that moving them to a > public api (mailet api) will be a good thing. Furthermore any change > like this should be discussed in the mailet-api list as we are not the > only implementors of the mailet-apis. I agree. d.
Re: [PROPOSAL] New Mailet Products
Danny Angus ha scritto: On Feb 4, 2008 9:58 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: Are you referring to the repositories api and the mailet v3 sandbox? Indirectly. I'm *not* proposing making big API changes, but moving James interfaces to mailet would let us do 99% of moving mailets out. I'm not sure Robert proposal is related to it Robert? I don;t see how we can move out mailets without doing that. d. In server-dev yesterday I wrote a big message about mailets with no dependencies on james server and mailets with minor utility dependencies (for which we could move the utility too) and mailets that requires a small refactoring to be able to move them out. It is a first step, and we will remain only james server specific mailets in james-server, so it will be easier to understand what interfaces we should place in the mailet api to move some or all of them to the standard mailet product. We are not happy with repository interfaces in james-server now (at least this is my understanding), so I'm not sure that moving them to a public api (mailet api) will be a good thing. Furthermore any change like this should be discussed in the mailet-api list as we are not the only implementors of the mailet-apis. Stefano
Re: [PROPOSAL] New Mailet Products
On Feb 4, 2008 9:58 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Are you referring to the repositories api and the mailet v3 sandbox? Indirectly. I'm *not* proposing making big API changes, but moving James interfaces to mailet would let us do 99% of moving mailets out. > > I'm not sure Robert proposal is related to it Robert? I don;t see how we can move out mailets without doing that. d.
Re: [PROPOSAL] New Mailet Products
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
Re: [PROPOSAL] New Mailet Products
Danny Angus ha scritto: I'd be in favour of this, in fact I'd be happy to do all the work on "std mailets", based on the sandbox work it would only take a couple of days. Are you referring to the repositories api and the mailet v3 sandbox? I'm not sure Robert proposal is related to it Robert? And I would prefer to see a release of the "old stuff" (with minor changes) using the new reorganized layout before we start to make big changes to mailet api. Stefano On Feb 3, 2008 7:41 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: 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.
Re: [PROPOSAL] New Mailet Products
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. 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? Stefano
Re: [PROPOSAL] New Mailet Products
I'd be in favour of this, in fact I'd be happy to do all the work on "std mailets", based on the sandbox work it would only take a couple of days. d. On Feb 3, 2008 7:41 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > 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. >
Re: [PROPOSAL] New Mailet Products
Robert Burrell Donkin wrote: 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. +1, thanks for starting this. Bernd
