james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject 3.0 Compatibility With 2.x [WAS Re: [crypto] Repackage?]
Date Tue, 18 Nov 2008 20:30:22 GMT
On Tue, Nov 18, 2008 at 9:19 AM, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>> On Mon, Nov 17, 2008 at 8:35 AM, Stefano Bagnara <apache@bago.org> wrote:

<snip>

>>> 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.

AIUI packaging is important for OSGi. splitting packages across jars
is not good. so i think it's worthwhile thinking about repackaging.

we're going to need new mailet loading mechanisms in any case. for
example, the sieve mailet needs an IoC mailet loader (eg spring).

<snip>

>>> 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.

ok

so: we're considering backwards compatibility for the config.xml (not
assembly etc) against the 2.3 user config.xml

AIUI no schema exists for config.xml so there isn't any clear way to
know exactly what this commitment would mean. perhaps we need to
create a clear schema for 2.3.

> 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.

i see your point. on the other hand, not offering an upgrade path for
existing users seems a little wrong.

i would really like to be able to load the configuration from more
than one document. i find a single configuration file inconvenient.

> 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).

if this is required for every possible combination of stores then this
would be a big commitment

if one standard store were picked then it might be feasible to offer
bidirectional compatibility just to that

- robert

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


Mime
View raw message