james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [crypto] Repackage?
Date Tue, 18 Nov 2008 09:19:12 GMT
Robert Burrell Donkin ha scritto:
> On Mon, Nov 17, 2008 at 8:35 AM, Stefano Bagnara <apache@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> ATM the cryptographic mailet code is packaged into:
>>> * org.apache.james.security
>>> (http://svn.apache.org/repos/asf/james/mailet/crypto/trunk/src/main/java/org/apache/james/security/)
>>> * org.apache.james.transport.mailets.smime
>>> (http://svn.apache.org/repos/asf/james/mailet/crypto/trunk/src/main/java/org/apache/james/transport/mailets/smime/)
>>> * org.apache.james.transport.matchers.smime
>>> (http://svn.apache.org/repos/asf/james/mailet/crypto/trunk/src/main/java/org/apache/james/transport/matchers/smime/)
>>> i was wondering about repackaging
>>> basing on 'org.apache.mailet.crypto' would follow the tentative
>>> convention adopted in base mailets but i'm open to suggestions
>>> opinions?
>> I'm fine with repackaging, but we should remember that this will mean
>> that we need many <mailetpackages>/<matcherpackages> in our config, and
>> that we won't provide backward compatibility for config.xml unless we
>> add some hardcoded hack or we add a compatibility layer with
>> matchers/mailets in the old places.
> crypto is little bit of a special case (it isn't in the 2.x code
> stream and it's not packaged now under o.a.j.transport)

Good point!

> but i agree that this is an issue that needs discussion before standard
>> I don't know anymore if we are still on a backward compatible config.xml
>> or if we decided to abandon that goal.
> IMHO more detail is needed about what a commitment means in detail
> are we committing to:
> 1. maintain compatibility with 2.3 or with earlier versions of 3.0?
> 2. maintain compatibility with custom configurations?

What we tried to commit in past was being able to start james trunk with
most james 2.3 user's *config.xml*. This meant adding many hacks every
time we changed the granularity of components in order to keep the old
conf working, or almost working.

IMHO either we keep this and really try to run james 2.3 config.xml or
we completely give up with phoenix style config.xml and introduce a
whole new method to configure. Having a similar config method with an
incompatible "runtime" will make people to try to use their config (even
if we explain what is compatible and what is not) and we'll spend too
much time in user support.

Furthermore IMO we should keep (or provide support for) *bidirectional*
compatibility for the storage layers (db/dbfile/file for
mail/spool/users repository). This is a must to let people try the new
code and eventually revert to their old installation if something does
not work as expected. As a system administrator I'll think thrice before
upgrading something that change my data format. We still have people
trying to use james 2.2.0 !?!?! and it is a PITA to support these people
(at least for me as I used james 2.2.0 more than 3 years ago the last time).


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message